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

Commentary: 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  stating that on any path , not only the path on which the referenced Destination Connection ID is used . 
 OK . It 's reasonable .
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 ).
The PATH_ABANDON frame informs the peer to abandon a path.
PATH_ABANDON frames MAY be sent on any path, not only the path on
which the referenced Destination Connection ID is used.
Draft: draft-ietf-quic-multipath

Commentary: Minor editorial suggestion .
Both endpoints, namely the client and the server, can close a path,
by sending PATH_ABANDON frame (see path-abandon-frame) which abandons
the path with a corresponding Path Identifier.  Once a path is marked
as "abandoned", it means that the resources related to the path, such
as the used connection IDs, can be released.  However, information
related to data delivered over that path SHOULD not be released
immediately as acknowledgments can still be received or other frames
that also may trigger retransmission of data on another path.
Both endpoints, namely the client and the server, can close a path,
by sending PATH_ABANDON frame (see path-abandon-frame) which abandons
the path with a corresponding Path Identifier.  The PATH_ABANDON
frame contains the Path Identifier and therefore can be sent on any
path.
Once a path is marked as "abandoned", it means that the resources
related to the path, such as the used connection IDs, can be
released.  However, information related to data delivered over that
path SHOULD not be released immediately as acknowledgments can still
be received or other frames that also may trigger retransmission of
data on another path.
Draft: draft-ietf-quic-multipath

Commentary: 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
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
multipath extension.  Further, this proposal only specifies a simple
basic packet scheduling algorithm, in order to provide some basic
implementation guidance.  However, more advanced algorithms as well
as potential extensions to enhance signaling of the current path
state are expected as future work.
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.
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
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
implementation guidance.  However, more advanced algorithms as well
as potential extensions to enhance signaling of the current path
state are expected as future work.
Draft: draft-ietf-quic-multipath

Commentary: as this is already stated normatively in RFC900 . 
 Currently the draft say : However , we should not use normative language in this draft but just point to RFC9000 instead as things are defined normatively there already . Btw . this reference should point to section 13.3 ( " Upon detecting losses , a sender MUST take appropriate congestion control action . " ) and 9.4 ( " Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path . " ) of RFC9000 specifically and maybe also to RFC9002 directly . 
 LGTMLGTM
Senders MUST manage per-path congestion status, and MUST NOT send
more data on a given path than congestion control on that path
allows.  This is already a requirement of QUIC-TRANSPORT.
When the QUIC multipath extension is used, senders manage per-path
congestion status as required in Section 9.4 of QUIC-TRANSPORT.
However, in QUIC-TRANSPORT only one active path is assumed and as
such the requirement is to reset the congestion control status on
path migration.  With the multipath extension, multiple paths can be
used simultaneously, therefore separate congestion control state is
maintained for each path.  This means a sender is not allowed to send
more data on a given path than congestion control for that path
indicates.
Draft: draft-ietf-quic-multipath

Commentary: Restructuring part II : This moves section on congestion control , packet scheduling , RTT calculation , and retransmission into the implementation guidance . These section do n't contain normative language but only guidance ( expect the congestion control one but that should probably be removed or potentially moved , see issue ) . None of the text is changed . Add a new section heading on " multipath operation with MPNSes " that clusters the sections on ack handling and protection as those things are impacted ( normatively ) by the introduction of MPNSes . No changes in the text accept some intro sentences to this new section heading . 
 Currently the draft say : However , we should not use normative language in this draft but just point to RFC9000 instead as things are defined normatively there already . Btw . this reference should point to section 13.3 ( " Upon detecting losses , a sender MUST take appropriate congestion control action . " ) and 9.4 ( " Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path . " ) of RFC9000 specifically and maybe also to RFC9002 directly .
The QUIC multipath extension uses different packet number spaces for
each path.  This also means that the same packet number can occur on
each path and the packet number is not a unique identifier anymore.
This requires changes to the ACK frame as well as packet protection
as described in the following subsections.
Draft: draft-ietf-quic-multipath

Commentary: Current text says that
As soon as the negotiation of multipath support with value 2 is
completed, endpoints SHOULD use ACK_MP frames instead of ACK frames
for acknowledgements of 1-RTT packets on path 0, as well as for 0-RTT
packets that are acknowledged after the handshake concluded.
As soon as the negotiation of multipath support is completed,
endpoints SHOULD use ACK_MP frames instead of ACK frames for
acknowledgements of 1-RTT packets on path 0, as well as for 0-RTT
packets that are acknowledged after the handshake concluded.
Draft: draft-ietf-quic-multipath

Commentary: Fix issue 
 In section 3 , we have However , the error code does not exist ( anymore ) , and I 'm not sure we need such a specific error code anyway . Why not raising a in such case ? 
 It 's reasonable to use TRANSPORTPARAMETERERROR . Submitted PR for this issue .
If endpoint receives an 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.
If endpoint receives an unexpected value for the transport parameter
"enable_multipath", it MUST treat this as a connection error of type
TRANSPORT_PARAMETER_ERROR (specified in Section 20.1 of QUIC-
TRANSPORT) and close the connection.
Draft: draft-ietf-quic-multipath

Commentary: Minor tweak . The text says that a path abandon " implies " retirement of the CID . Readers could be mislead and assume that they do n't need to send a retire frame after sending abandon , when in fact they do . 
 , please review . 
 This Github setting is pretty annoying . 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 .
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).
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 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).
Draft: draft-ietf-quic-multipath

Commentary: For issue , add some considerations for RTT computation in our single pns implementation . Not sure if it is easy enough to understand . Please feel free to change . 
 Yes , this needs more discussion . Also maybe we want to move this text rather in the " Implementation Considerations " section ? 
 updated this PR . Can we merge it ? Note that this PR is only for SPNS and part of that respective section . Based on his report , the strategy seems reasonable . For ACKMP we have the following text in the packet scheduling section ( 7 . ): 
 Comment by ( on PR ): I think we expand this section a bit as we found getting the delay right was non - trivial . QUIC time - stamp would work for sure . But if one decides not to use QUIC timestamp , we probably want to explain what is needed to be done here . 
 I have submitted PR for this one . 
 Closing as got merged . 
 I 'm ok with the current version , just a few editorial hints . Seems like a reasonable tradeoff , easy to implement .
Maintain an ACK threshold and an ACK timer for each path.  A path
should send an ACK when it receives ack-eliciting-threshold number
of ack-eliciting packets (e.g., two) on this path, and an ack-
eliciting packet must be acknowledged within MAX_ACK_DELAY.
Write ACK frame based on the largest received packet of the path.
Start the ACK ranges with the largest received packet number of
that path, which means that the "Largest Acknowledged" field is
the path's largest packet number and the "ACK Delay" field is the
delay time of the path's largest received packet.
Maintain an unacked list for each path to retrieve the packets
that has been sent when an ACK is received.  It can coexist with
the unacked list of the connection layer or packet number space
layer.
Generate RTT sample for a path when the following conditions are
met: (1) the largest acknowledged packet number is newly
acknowledged by the ACK received from this path, and (2) at least
one of the newly acknowledged packets was ack-eliciting.
Draft: draft-ietf-quic-multipath

Commentary: I believe we can merge this now as it is . If we want to add more guidance later we should open a separate issue and another PR . 
 This issue came up during the discussion of issue . We say that ACK or ACK_MP frames can be send over any path , however , maybe we should discuss some guidance and trade - offs . E.g. sending on the same path as the packets received also for RTT measurements ; using the shortest delay path might have some performance benefits ... ? 
 I agree . We should add some guidance here . We did some experiment regarding this issue . Our finding is returning ACK on the shortest path is helpful . But the improvement is only more significant when the path rtt ratio is larger than 4:1 .
Note that the receiver could use a different scheduling strategy to
send ACK(_MP) frames.  The recommended default behaviour consists in
sending ACK(_MP) frames on the path they acknowledge packets.  Other
scheduling strategies, such as sending ACK(_MP) frames on the lowest
latency path, might be considered, but they could impact the sender
with side effects on, e.g., the RTT estimation or the congestion
control scheme.  When adopting such asymetrical acknowledgment
scheduling, the receiver should at least ensure that the sender
negotiated one-way delay calculation mechanism (e.g., QUIC-
Timestamp).
Draft: draft-ietf-quic-multipath

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

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

Commentary: It 's a grammar error fix in the aead section . 
 from 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  ! I fixed this grammar error in PR .
The path ID for 1-RTT packets is the sequence number of of QUIC-
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
specification a range of less than 2^32-1 values MUST be used before
updating the packet protection key.
The path ID for 1-RTT packets is the sequence number of QUIC-
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
specification a range of less than 2^32-1 values MUST be used before
updating the packet protection key.
Draft: draft-ietf-quic-multipath

Commentary: This text will be moved to the next section in PR . Therefore this PR needs to be merged together with PR .
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.
This extension does not change the definition of any transport
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.
This extension does not change the definition of any transport
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.
Draft: draft-ietf-quic-multipath

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

Commentary: 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 .
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.
After completing the handshake, endpoints have agreed to enable
multipath feature and can start using multiple paths.  This document
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.
Draft: draft-ietf-quic-multipath

Commentary: This text is mostly taken from PR but with some edits 
 I agree with the intent , but please simplify the heading text and avoid making debatable statements about QUIC - TRANSPORT.At this stage , we know that the best strategy will be a function of the application and of its traffic pattern and requirements , but we can not specify it . Looks good .
Simultaneous use of multiple paths enables different retransmission
strategies to cope with losses such as: a) retransmitting lost frames
over the same path, b) retransmitting lost frames on a different or
dedicated path, and c) duplicate lost frames on several paths (not
recommended for general purpose use due to the network overhead).
While this document does not preclude a specific strategy, more
detailed specification is out of scope.