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

Commentary: To estimate path delay accurately , loss recovery of QUIC utilizes the ACK Delay field of ACK frame ( see ) . However , when single packet number space is being used , it is difficult for the sender to obtain ACK Delay for all the paths being used , because ACK Delay is reported only for the packet carrying the largest packet number . It is the only the ACK delay of the path with shortest path - delay that can be reported . I think it might be a good idea to acknowledge this shortcoming in the documentation , so that we do not miss the downside when we compare the approaches ( or when we try to address the shortcomings of the single packet number space approach ) . 
 I agree that this issue should be addressed in the current draft . Regarding the problem itself , I think using the one - way timestamp can solve this problem for single PN . 
 I believe this is discussed in section 5 : Can you propose a PR if you think more text is useful ? ! 
 I think Section 5 should relate to both packet number space designs , while this issue is specific to one . I summarised the discussion in . 
 We move section 5 from the single packet number section into an own section , as we agreed that it is applicable to both cases as we do n't require ack to be send on the same path and the packet was received . I also do n't understand the point about being only able to measure the shortest path with a single PN space . It kind of randomly depends on with packet you ack as discussed in section 5 . If we want to add some additional consideration we should probably add them to section 5 . 
 Yes , there is an issue with single space here . Suppose that the sender sends packets 1 and later 3 on path long delay path A , packets 2 and later 4 on short delay path B. The receiver will get the packets in the order 2 , 1 , 4 , 2 . The ACK will be : ACK , highest = 2 . Ack delay = time ACK sent minus time 2 received . ACK , highest = 2 , also ACK 1 . Ack delay = time ACK sent minus time 2 received . ACK , highest = 4 , also ACK 2 and 1 . Ack delay = time ACK sent minus time 4 received . ACK , highest = 4 , also ACK 3 , 2 and 1 . Ack delay = time ACK sent minus time 4 received . The RTT of path B will be evaluated precisely , with the help of the ACK delay . The RTT of path A will be evaluated less precisely . When the ACK of 2 and 1 is received , the sender can not use the ACK delay to narrow the estimate of the RTT of path A. Same for packet 4 . 
 Looks good .
The ACK Delay field of the ACK frame is relative to the largest
acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT).
When using paths with different transmission delays, the reported
host delay will most of the time relate to the path with the shortest
latency.  To collect ACK delays on all the paths, hosts should rely
on time stamps as described in QUIC-Timestamp.
Draft: draft-lmbdhk-quic-multipath

Commentary: fixes issue 
 Good point but I guess this definition is inline with what 's already specified for QUIC given NATs ... 
 Consider adding this entry to the terminology section : This also clarifies the link with " network path " in RFC9000 . 
 PR merged 
 Note that this definition is different from RFC6182 that required the utilization of at least one different addresses for different subflows . In practice , there were deployments where this requirement was not respected and it was overly conservative .
Path: refers to the 4-tuple {source IP address, source port
number, destination IP address, destination port number}. A path
refers to "network path" used in QUIC-TRANSPORT.
Draft: draft-lmbdhk-quic-multipath

Commentary: Thanks for the fixes , !
Before the client opens a new path by sending an packet on that path
with a PATH_CHALLENGE frame, it has to check. whether there is an
unused Connection IDs available for each side.  In this example the
client chooses the Connection ID S2 as the Destination Connection ID
in the new path.
Before the client opens a new path by sending an packet on that path
with a PATH_CHALLENGE frame, it has to check whether there is an
unused Connection IDs available for each side.  In this example the
client chooses the Connection ID S2 as the Destination Connection ID
in the new path.
Thee client initiates the path closure for the path with ID 1 by
sending a packet with an PATH_ABANDON frame.  When the server
received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame
in the next packet.  Afterwards the connection IDs in both directions
can be retired using the RETIRE_CONNECTION_ID frame.
The client initiates the path closure for the path with ID 1 by
sending a packet with an PATH_ABANDON frame.  When the server
received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame
in the next packet.  Afterwards the connection IDs in both directions
can be retired using the RETIRE_CONNECTION_ID frame.
Draft: draft-lmbdhk-quic-multipath

Commentary: That indeed should be " path " .
If connection IDs are used, PATH_ABANDON frames can be sent on any
path, not only the path that is intended to be closed.  Thus a
connection can be abandoned even if connectivity on that path is
already broken.  If no connection IDs are used and the PATH_ABANDON
frame has to sent on the path that is intended to be closed, it is
possible that the packet containing the PATH_ABANDON frame or the
packet containing the ACK for the PATH_ABANDON frame cannot be
received anymore and the endpoint might need to rely on an idle time
out to close the path, as described in Section idle-time-close.
If connection IDs are used, PATH_ABANDON frames can be sent on any
path, not only the path that is intended to be closed.  Thus a path
can be abandoned even if connectivity on that path is already broken.
If no connection IDs are used and the PATH_ABANDON frame has to sent
on the path that is intended to be closed, it is possible that the
packet containing the PATH_ABANDON frame or the packet containing the
ACK for the PATH_ABANDON frame cannot be received anymore and the
endpoint might need to rely on an idle time out to close the path, as
described in Section idle-time-close.
Draft: draft-lmbdhk-quic-multipath

Commentary: ( OK , so it 's not the biggest contribution I 've ever made , but I DID notice it , while reading the master branch ... 
 This relates to only one typo , so I merge this PR . 
 Thanks for correcting this !
In order to guarantee the uniqueness of the None, the nonce N is
calculated by combining the packet protection IV with the packet
number and with the path identifier.
In order to guarantee the uniqueness of the nonce, the nonce N is
calculated by combining the packet protection IV with the packet
number and with the path identifier.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 
 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 . 
 please review PR 
 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 that also works for me ! 
 LTGTM just 2 nits
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 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.
Draft: draft-lmbdhk-quic-multipath

Commentary: Be consistent with title . 
 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
Path Identifier (Path ID): An identifier that is used to identify
a path in a QUIC connection at an endpoint.  Path Identifier is
used in multi-path control frames (etc.  PATH_ABANDON frame) to
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
length of that connection ID is zero.
Path Identifier (Path ID): An identifier that is used to identify
a path in a QUIC connection at an endpoint.  Path Identifier is
used in multipath control frames (etc.  PATH_ABANDON frame) to
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
length of that connection ID is zero.
Multi-path QUIC transport error codes are 62-bit unsigned integers
following QUIC-TRANSPORT.
Multipath QUIC transport error codes are 62-bit unsigned integers
following QUIC-TRANSPORT.
Draft: draft-lmbdhk-quic-multipath

Commentary: Each line is limited to 72 characters . 
 I verified that this PR produces the draft that we expect . I did one small change : remove spaces at the end of lines . 
 There are many isntances in the markdown source where a whole paragraph is entered in a single line of text . This makes the reviewing harder , and messes up the " what changed " view when reviewing PRs . 
 Just to be on the same page , how should we format the text ? I see two possible ways . Hard - constraint the number of characters per line to a given limit ( e.g. , 80 ) Make one sentence = one line I have a slight preference for option 2 , but I can of course live with the other or a mix of both . 
 I would prefer something like 72 characters , because the last 8 positions are used for numbering the cards in your deck .
Packet protection for QUIC version 1 is specified is Section 5 of
QUIC-TLS.  The general principles of packet protection are not
changed for QUIC Multipath.  No changes are needed for setting packet
protection keys, initial secrets, header protection, use of 0-RTT
keys, receiving out-of-order protected packets, receiving protected
packets, or retry packet integrity.  However, the use of multiple
number spaces for 1-RTT packets requires changes in AEAD usage.
Packet protection for QUIC version 1 is specified in Section 5 of
QUIC-TLS.  The general principles of packet protection are not
changed for QUIC Multipath.  No changes are needed for setting packet
protection keys, initial secrets, header protection, use of 0-RTT
keys, receiving out-of-order protected packets, receiving protected
packets, or retry packet integrity.  However, the use of multiple
number spaces for 1-RTT packets requires changes in AEAD usage.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 can not 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 do n't . 
 please review PR 
 Looks good to me . Thanks .
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.
value: 0 (default) for disabled.
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.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 changes of the tag " mp - ack - frame " to " ack - mp - frame " for consistency ...
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
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
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.
Therefore, the packet number space for 1-RTT packets can be
identified based on the Destination Connection ID in each packets.
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
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
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.
Therefore, the packet number space for 1-RTT packets can be
identified based on the Destination Connection ID in each packets.
ACK_MP frame mp-ack-frame can be returned via either a different
path, or the same path identified by the Path Identifier, based on
different strategies of sending ACK_MP frames.
ACK_MP frame ack-mp-frame can be returned via either a different
path, or the same path identified by the Path Identifier, based on
different strategies of sending ACK_MP frames.
ACK_MP frame is formatted as shown in fig-mp-ack-format.
ACK_MP frame is formatted as shown in fig-ack-mp-format.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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
This proposal supports the negotiation of either the use of one
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
difference latencies, this approach requires the use of a connection
ID.  Therefore use of a single number space can be beneficial in
highly constrained networks that do not benefit from exposing the
connection ID in the header.  More evaluation and implementation
experience is needed to select one approach before final
publlication.
Draft: draft-lmbdhk-quic-multipath

Commentary: Some more text for the scheduling section to clarify it . 
 A suggestion to resolve  's point , also agree on the proposed change in line 248 .
After completing the handshake, endpoints have agreed to enable
multipath feature and can start using multiple paths.
After completing the handshake, endpoints have agreed to enable
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.
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.
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.
Draft: draft-lmbdhk-quic-multipath

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

Commentary: I opened issue to make sure we don forget to address this and will instead .
As currently defined in this version of the draft the use of multiple
packet number spaces requires the use of connection IDs is both
directions.  Today's deployments often only use destination
connection ID when sending packets from the client to the server as
this addresses the most important use cases for migration, like NAT
rebinding or mobility events.  Further discussion and work is
required to evaluate if the use of multiple packet number spaces
could be supported as well when the connection ID is only present in
one direction.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 . please review and merge if you agree !
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.
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 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.
Draft: draft-lmbdhk-quic-multipath

Commentary: 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 .
Path Identifier Content: A variable-length integer specifying the
path identifier.
Path Identifier Content: A variable-length integer specifying the
path identifier.  If Identifier Type is 2, the Path Identifier
Content MUST be empty.