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

Commentary: It might pay to reconcile : { { vars - of - interest } } ) to be larger than the congestion window , unless the packet is sent on a PTO timer expiration ; see { { pto } } . And now exceeds the recently reduced congestion window . Now , you might implement the latter using PTO machinery , but that text does n't really suggest that in any way . 
 Where does this second sentence come from ? I 'm pretty sure I have n't implemented anything like this in quic - go . Should I ? 
 That sentence is the the definition of the . We have n't implemented that either , and I was wondering if it truly helps . 
 For TCP this second case if important because as long as you do n't retransmit the lost packet you will not get any ACK that acknowledges new data . I guess we do n't need that for QUIC . 
 The second sentence was later in , and the MUST was n't updated , so I 'll fix that . Chromium currently implements PRR(RFC6937 ) , which is a more complex variant of this which is designed to keep the ACK clock going . I thought we discussed adding an informative reference to PRR when we this text , and I 'm not sure why we did n't . 
 seems to be the wrong issue you are pointed to ... 
 Good catch , it 's 
 I 've suggested some symbolic references .
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 at the transport layer, offering comparable
security to running TLS over TCP, with the improved connection setup
latency of TCP Fast Open RFC7413.
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 TLS13 at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open TFO.
Draft: draft-ietf-quic-http

Commentary: Follow - up to 
 Or " for indicating " : man_shrugging : not sure what the most appropriate one is .
Paragraph (version A):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI) RFC6066 TLS extension unless an alternative
mechanism for indicate the target host is used.
Paragraph (version B):
QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol.  HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake.  If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI) RFC6066 TLS extension unless an alternative
mechanism to indicate the target host is used.
Draft: draft-ietf-quic-recovery

Commentary: I believe this section was mistakenly on the wrong level . I also a reference to a later section to the last sentence . Alternatively this sentence could just be removed as this is normatively specified later on .
Paragraph (version A):
Initial packets and Handshake packets could be never acknowledged,
but they are removed from bytes in flight when the Initial and
Handshake keys are discarded.  When Initial or Handshake keys are
discarded, the PTO and loss detection timers MUST be reset, because
discarding keys indicates forward progress and the loss detection
timer may have been set for a now discarded packet number space.
Paragraph (version B):
Initial packets and Handshake packets could be never acknowledged,
but they are removed from bytes in flight when the Initial and
Handshake keys are discarded, as described below in Section
discarding-packets.  When Initial or Handshake keys are discarded,
the PTO and loss detection timers MUST be reset, because discarding
keys indicates forward progress and the loss detection timer might
have been set for a now discarded packet number space.
Draft: draft-ietf-quic-recovery

Commentary: by clarifying that one may start with a smaller time threshold , not a smaller packet threshold . 
 The doc says : " Implementations that detect spurious retransmissions and increase the reordering threshold in packets or time MAY choose to start with smaller initial reordering thresholds to minimize recovery latency . " For the packet based threshold does that this say that a smaller initial value than 3 packets could be used ? Is that really sensible ? And for a time based threshold I do n't really understand what this means because the threshold is anyway calculated dynamically based on the RTT , so there is no real initial value . I guess there was a time when the threshold was a fixed value and this sentence is maybe a left - over ? 
 Given the current guidance to never use packet thresholds below 3 , I think this text should be changed to be clear that you can start with a smaller fraction of RTT and it only applies to time threshold . 
 I think the fix will be editorial , but once a PR is out we 'll know for sure . 
 If it 's only about time - based threshold , any advise should be moved in the respective subsection . However , I would also be okay to just remove this sentence / paragraph ...
Paragraph (version A):
Spuriously declaring packets as lost leads to unnecessary
retransmissions and may result in degraded performance due to the
actions of the congestion controller upon detecting loss.
Implementations that detect spurious retransmissions and increase the
reordering threshold in packets or time MAY choose to start with
smaller initial reordering thresholds to minimize recovery latency.
Paragraph (version B):
Spuriously declaring packets as lost leads to unnecessary
retransmissions and may result in degraded performance due to the
actions of the congestion controller upon detecting loss.
Implementations can detect spurious retransmissions and increase the
reordering threshold in packets or time to reduce future spurious
retransmissions and loss events.  Implementations with adaptive time
thresholds MAY choose to start with smaller initial reordering
thresholds to minimize recovery latency.
Draft: draft-ietf-quic-recovery

Commentary: In recovery for maxackdelay of 0 . 
 Section 5.2.1 of -recovery-25 says : However , Section 13.2.5 of -transport-25 does n't actually say that ( anymore ? ) Section 13.2.1 says so I guess at least the reference is incorrect . But since Section 19.3 only has a SHOULD for encoding zero and the pseudo code simply uses the encoded ACK delay , if the ACK sender does n't encode zero , the ACK receiver will compute its RTT based on the encoded ACK delay . 
 The intent is to use 0 as a peer maxackdelay for the Initial and Handshake packet number spaces . The pseudocode says : ackdelay = min(Ack  in ACK Frame , maxack_delay ) So for Initial and Handshake , min(Ack  , 0 ) = 0 The text in the " Estimating smoothed RTT and RTTVar " section is fairly clear I think ? I fixed the section reference in 
 I understood the in the to be the value of the transport parameter ? 
 Not for Initial and Handshake PN spaces . Would it be helpful to have a comment above the min ( ) in the pseudocode ? 
 That would at least help me ( pointing out it is NOT the value of the TP , although the name is the same . ) 
 I noticed the pseudocode before UpdateRtt ( ) already makes this fairly clear . I can fold the pnspace check into UpdateRtt if you think it would read more clearly ? 
 Ah , so we are not limiting , we are overwriting .
Paragraph (version A):
The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet.  This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variation in the
estimate (4*rttvar), and max_ack_delay, to account for the maximum
time by which a receiver might delay sending an acknowledgement.
When the PTO is armed for Initial or Handshake packet number spaces,
the max_ack_delay is 0, as specified in 13.2.5 of QUIC-TRANSPORT.
Paragraph (version B):
The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet.  This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variation in the
estimate (4*rttvar), and max_ack_delay, to account for the maximum
time by which a receiver might delay sending an acknowledgement.
When the PTO is armed for Initial or Handshake packet number spaces,
the max_ack_delay is 0, as specified in 13.2.1 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-qpack

Commentary: Much belated , this attempts to address the concerns about deadlocking . Basically , this says that you should avoid instructions that do n't have flow control credit . It does n't say how an encoder might learn what limits are , but we 've seen a range of tactics being used in implementations and I do n't want to get into transport API debates . This does n't cover the memory exhaustion attack that suggests on the issue ; I think that is better covered more generally by the connection - level flow control limits . 
 I debated adding another paragraph : 
 Thanks for adding this !
Paragraph (version B):
Writing instructions on streams that are limited by flow control can
produce deadlocks.
Paragraph (version B):
A decoder might stop issuing flow control credit on the stream that
carries a header block until the necessary updates are received on
the encoder stream.  If the granting of flow control credit on the
encoder stream (or the connection as a whole) depends on the
consumption and release of data on the stream carrying the header
block, a deadlock might result.
Paragraph (version B):
More generally, a stream containing a large instruction can become
deadlocked if the decoder withholds flow control credit until the
instruction is completely received.
Paragraph (version B):
To avoid these deadlocks, an encoder SHOULD avoid writing an
instruction unless sufficient stream and connection flow control
credit is available for the entire instruction.
Draft: draft-ietf-quic-recovery

Commentary: Currently , the " Ignoring Loss of Undecryptable Packets " section indicates that some loss can be ignored , but now that we have multiple packet number spaces , I think we can constrain the set of ignorable losses to those below the smallest acknowledged packet in a packet number space . Ignoring the loss of a subsequently sent packet was not the intent . 
 I might have to put in a lint for HTAB ...
Paragraph (version A):
During the handshake, some packet protection keys might not be
available when a packet arrives.  In particular, Handshake and 0-RTT
packets cannot be processed until the Initial packets arrive, and
1-RTT packets cannot be processed until the handshake completes.
Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets
that might arrive before the peer has packet protection keys to
process those packets.
Paragraph (version B):
During the handshake, some packet protection keys might not be
available when a packet arrives and the receiver can choose to drop
the packet.  In particular, Handshake and 0-RTT packets cannot be
processed until the Initial packets arrive and 1-RTT packets cannot
be processed until the handshake completes.  Endpoints MAY ignore the
loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived
before the peer had packet protection keys to process those packets.
Endpoints MUST NOT ignore the loss of packets that were sent after
the earliest acknowledged packet in a given packet number space.
Draft: draft-ietf-quic-transport

Commentary: From and comments on 
 In I received a number of comments on the existing text from and . This is an issue to track improving that text in a separate PR . One suggestion was to introduce an ITO(Idle Timeout ) acronym . 
 thinks cognitive load is increased by ITO and it 's not that much shorter , so let 's not do that .
Paragraph (version A):
An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully.  The idle timer is also
restarted when sending an ack-eliciting packet (see QUIC-RECOVERY),
but only if no other ack-eliciting packets have been sent since last
receiving a packet.  Restarting when sending packets ensures that
connections do not prematurely time out when initiating new activity.
An endpoint might need to send packets to avoid an idle timeout if it
is unable to send application data due to being blocked on flow
control limits; see flow-control.
Paragraph (version A):
An endpoint that sends packets near the end of the idle timeout
period risks having those packets discarded if its peer enters the
draining state before the packets arrive.  If a peer could time out
within a Probe Timeout (PTO; see Section 6.6 of QUIC-RECOVERY), it is
advisable to test for liveness before sending any data that cannot be
retried safely.  Note that it is likely that only applications or
application protocols will know what information can be retried.
Paragraph (version B):
An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully.  The idle timer is also
restarted when sending the first ack-eliciting packet (see QUIC-
RECOVERY) after receiving a packet.  Restarting when sending packets
ensures that connections do not prematurely time out when initiating
new activity.  Only restarting when sending after receipt of a packet
ensures the idle timeout is not excessively lengthened past the time
the peer's timeout has expired.  An endpoint might need to send
packets to avoid an idle timeout if it is unable to send application
data due to being blocked on flow control limits; see flow-control.
Paragraph (version B):
An endpoint that sends packets near the end of the idle timeout
period risks having those packets discarded if its peer enters the
draining state before the packets arrive.  If a peer could time out
within a Probe Timeout (PTO; see Section 6.6 of QUIC-RECOVERY), it is
advisable to probe the path with an ack-eliciting packet to ensure
the connection is still responsive before sending any data that
cannot be retried safely.  Note that it is likely that only
applications or application protocols will know what information can
be retried.
Draft: draft-ietf-quic-recovery

Commentary: Similar to TCP as described in Section 5 of RFC 6675 
 Should we restrict this to retransmittable frames that were lost in the packet ? If it was a small packet , can I pack to the MTU ? What about pure ACKs that I 've declared lost ? 
 Those are great questions . There are two goals in my mind . The first is to ensure loss recovery is not unnecessarily slower than TCP . The second is to ensure this behavior is n't significantly more aggressive than TCP . But within those bounds , I 'm inclined to not be too restrictive , if that makes sense ? Suggestions welcome if you think they 'd be an improvement . 
 Well the pedantic answer is that TCP would only detect a loss if there was something in the bytestream . the QUIC equivalents would then be any packet that contained STREAM , CRYPTO , MAXSTREAMDATA , etc , plus any packet that flipped the key update bit . But not ACK , MAX_DATA , and other things that are in the TCP header . That is obviously a dumb way to approach things . I do n't actually have a strong opinion on this one way of the other , but if I read the draft correctly , the loss of an ACK - only packet will affect cwnd in QUIC but not TCP ( granted , a cwnd - constrained endpoint sending pure ACKs is a corner case ) . So I guess I 'd err on the side of permitting the packet in response to loss of an ACK , as we 're already quite a bit less aggressive than TCP in that case . Anyway , do we want any normative language against , say , using this permission to send high - priority new data instead of the lost data ? 
 Adding language against sending new data or data besides data that 's been lost couples the " can I send " with " what should I send " questions more than I would like unless it 's absolutely critical . FYI , to be declared lost , it must be in - flight : " A packet is declared lost if it meets all the following conditions : The packet is unacknowledged , in - flight , and was sent prior to an acknowledged packet . " 
 Ah , I think we 're fine then . 
 TCP recommends that a sender retransmit a packet immediately upon detecting the first loss in a recovery window ( see Section 3.2 , second para , of RFC 5681 ; Section 5 of RFC 6675 seems to follow the same idea ) . QUIC should at least allow the same . Not doing this can delay loss recovery by 0.5 RTT , which is not great . This replaces ; this is a more correct description of the problem , which is a design issue . 
 Discussed in ZRH . Proposed resolution is to get a PR done .
Paragraph (version B):
When entering recovery, a single packet MAY be sent even if bytes in
flight now exceeds the recently reduced congestion window.  This
speeds up loss recovery if the data in the lost packet is
retransmitted and is similar to TCP as described in Section 5 of
RFC6675.  If further packets are lost while the sender is in
recovery, sending any packets in response MUST obey the congestion
window limit.
Draft: draft-ietf-quic-recovery

Commentary: and by documenting the core difference between TCP 's RTO and QUIC 's PTO . 
 QUIC : TCP : 
 Discussed in ZRH . Difference to be explained as an editorial comment . 
 Specifically , we 'll add some text that describes how PTO in QUIC is different than RTO and TLP in TCP . 
 " When an ACK frame is received that establishes loss of all in - flight packets sent over a long enough period of time , the network is considered to be experiencing persistent congestion . " QUIC declares persistent congestion only upon receipt of an ACK for a packet sent after entering loss recovery . This means that the cwnd will remain large and usable even if there is prolonged network silence with packets outstanding . If the state of the transport was application limited , this can cause a large burst on the network . In TCP , an RTO causes immediate drop of the cwnd to min_cwnd . Ideally QUIC should drop the cwnd in the same timescale as TCP would . Typically minrto for the Internet is 200 msec or 300 msec ( and larger if the RTT is larger ) . 
 I do not want to change the existing algorithm , because the app - limited case is the case when the sender is strictly less aggressive than the congestion controller limits , so I believe it 's less likely to cause issues for the network . I can write text pointing out this difference . 
 Discussed in ZRH . Proposed resolution is to close with no action . Editorial issue to explain the difference to TCP and its safety . 
 this was in the latest batch of consensus calls , but you did n't mark it has having consensus . Can you review please ? 
 You are correct , I missed this one somehow sorry so moving to has consensus 
 LGTM
Paragraph (version B):
In doing this, QUIC avoids unnecessary congestion window reductions,
obviating the need for correcting mechanisms such as F-RTO RFC5682.
Since QUIC does not collapse the congestion window on a PTO
expiration, a QUIC sender is not limited from sending more in-flight
packets after a PTO expiration if it still has available congestion
window.  This occurs when a sender is application-limited and the PTO
timer expires.  This is more aggressive than TCP's RTO mechanism when
application-limited, but identical when not application-limited.
Draft: draft-ietf-quic-http

Commentary: This goes most of the way to solving my perceived problem . I do wonder if we should also add a little bit more text to section 8 in this paragraph under certain circumstances . Implementations need to consider the impact on outstanding requests before making this choice . Perhaps just a reference e.g. " Implementations need to consider the impact on outstanding requests before making this choice , see { immediate - application - closure } . " 
 But that section does n't discuss the impact on outstanding requests , and it seems irrelevant to this topic . Can you expand on the connection you see ? 
 to me , the choice to promote a stream error to a connection error is the choice to promote it to an immediate application close . Therefore the present statement about " impact on outstanding requests " is really about how to do / decide on graceful close with GOAWAY . If that is not the case , then I do n't understand what other consierations my endpoint should make 
 That text was as a compromise , basically reminding implementations that choosing to blow up their connection will lose any requests in flight , so you should have a good reason . 
 I 'm going to go ahead and merge this , since it addresses the original issue and stands by itself . If you think we need additional text elsewhere , can you open a separate issue ? 
 Sure thing , I 'll review again 
 Draft 25 section 5.3 says : any time . This results in sending a QUIC CONNECTIONCLOSE frame to the peer ; the error code in this frame indicates to the peer why the connection is being closed . This does n't specifically tie down H3 - initiated closure to only use the application variant of CONNECTIONCLOSE ( 0x1d ) . This gets a bit strange when combined with later guidance to use H3 error codes or treat unknown error codes as
Paragraph (version A):
An HTTP/3 implementation can immediately close the QUIC connection at
any time.  This results in sending a QUIC CONNECTION_CLOSE frame to
the peer; the error code in this frame indicates to the peer why the
connection is being closed.  See errors for error codes which can be
used when closing a connection.
Paragraph (version B):
An HTTP/3 implementation can immediately close the QUIC connection at
any time.  This results in sending a QUIC CONNECTION_CLOSE frame to
the peer indicating that the application layer has terminated the
connection.  The application error code in this frame indicates to
the peer why the connection is being closed.  See errors for error
codes which can be used when closing a connection in HTTP/3.
Draft: draft-ietf-quic-transport

Commentary: The SHOULD is guidance for future extensions ; if we 'd like to downgrade that to non - normative , that 's also fine . 
 I 'm going to merge this . 
 Resolution of was to have no design change , but consider a " here be dragons " warning in the extension section paralleling what was to HTTP/3 in . ( The reasons , and therefore the guidance , are different at the transport layer -- we ca n't directly steal the text . )
Paragraph (version B):
Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other
extensions which modify or replace the same functionality unless the
behavior of the combination is explicitly defined.  Such extensions
SHOULD define their interaction with previously-defined extensions
modifying the same protocol components.
Draft: draft-ietf-quic-transport

Commentary: I believe this is an improvement , though I 'm unsure all the comments are included . PTAL . 
 Thanks suggestions accepted . 
 In I received a number of comments on the existing text from and . This is an issue to track improving that text in a separate PR . One suggestion was to introduce an ITO(Idle Timeout ) acronym . 
 thinks cognitive load is increased by ITO and it 's not that much shorter , so let 's not do that . 
 a few suggestions
Paragraph (version A):
During connection establishment, both endpoints make authenticated
declarations of their transport parameters.  These declarations are
made unilaterally by each endpoint.  Endpoints are required to comply
with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling.
Paragraph (version B):
Transport parameters are declarations that are made unilaterally by
each endpoint.  Each endpoint can choose values for transport
parameters independent of the values chosen by its peer.