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

Commentary: From a full read en route to Prague . 
 Thanks  , suggestions taken and " Clearer Loss Epoch " rewritten .
Paragraph (version A):
Packets are considered in-flight when they have been sent and
neither acknowledged nor declared lost, and they are not ACK-only.
Paragraph (version B):
Packets are considered in-flight when they have been sent and are
not ACK-only, and they are not acknowledged, declared lost, or
abandoned along with old keys.
Paragraph (version B):
QUIC ends a loss epoch when a packet sent after loss is declared is
acknowledged.  TCP waits for the gap in the sequence number space to
be filled, and so if a segment is lost multiple times in a row, the
loss epoch may not end for several round trips.  Because both should
reduce their congestion windows only once per epoch, QUIC will do it
correctly once for every round trip that experiences loss, while TCP
may only do it once across multiple round trips.
Paragraph (version A):
Once a later packet has been acknowledged, an endpoint SHOULD declare
an earlier packet lost if it was sent a threshold amount of time in
the past.  The time threshold is computed as kTimeThreshold *
max(SRTT, latest_RTT).  If packets sent prior to the largest
acknowledged packet cannot yet be declared lost, then a timer SHOULD
be set for the remaining time.
Paragraph (version B):
Once a later packet packet within the same packet number space has
been acknowledged, an endpoint SHOULD declare an earlier packet lost
if it was sent a threshold amount of time in the past.  To avoid
declaring packets as lost too early, this time threshold MUST be set
to at least kGranularity.  The time threshold is: ~~~ kTimeThreshold
* max(SRTT, latest_RTT, kGranularity) ~~~ If packets sent prior to
the largest acknowledged packet cannot yet be declared lost, then a
timer SHOULD be set for the remaining time.
Paragraph (version A):
An endpoint might consistently record RTT samples as 0 in extremely
low latency networks, leading to a smoothed_rtt of 0.  Consequently,
the endpoint could declare all earlier packets as lost immediately
upon receiving an acknowledgement for a later packet.  That is, the
endpoint would not provide any reordering tolerance.  To avoid
declaring packets as lost too early, the time threshold MUST be set
to at least kGranularity (defined in ld-consts-of-interest).
Paragraph (version A):
QUIC begins every connection in slow start and exits slow start upon
loss or upon increase in the ECN-CE counter.  QUIC re-enters slow
start anytime the congestion window is less than ssthresh, which
typically only occurs after an PTO.  While in slow start, QUIC
increases the congestion window by the number of bytes acknowledged
when each acknowledgment is processed.
Paragraph (version B):
QUIC begins every connection in slow start and exits slow start upon
loss or upon increase in the ECN-CE counter.  QUIC re-enters slow
start anytime the congestion window is less than ssthresh, which only
occurs after persistent congestion is declared.  While in slow start,
QUIC increases the congestion window by the number of bytes
acknowledged when each acknowledgment is processed.
Draft: draft-ietf-quic-http

Commentary: Technically design , but barely . 
 Originally posted by in There are three reasonable places to blow up : When you decide to stop reading a critical stream ( i.e. when  is sent ) When you discover the peer has stopped reading a critical stream ( i.e. when  is received ) When you discover the peer has closed a critical stream ( when RESETSTREAM or FIN is received ) My inclination would be to advise against FIN / SS / R_S on a critical stream and mandate connection termination on receipt of any of them . 
 Completely agree . This seems like the simplest and most obvious solution . 
 SGTM mike 
 Note that this PR does NOT address , just a comment that came up there . 
 Re - reading this , I think the existing text is pretty good ; it just needs a little reframing . The existing requirement is to error out " If the control stream is closed at any point , " without reference to whether it was closed because the peer send a FIN / RESET on their control stream or you obeyed a STOP_SENDING on yours . I think I 'll add a requirement not to request closure of a control stream ; do you think we need more elucidation here ? 
 nits , but LGTM
Paragraph (version A):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS.  Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control
stream.  If the control stream is closed at any point, this MUST be
treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS.  Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control
stream, and the receiver MUST NOT request that the sender close the
control stream.  If either control stream is closed at any point,
this MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Draft: draft-ietf-quic-http

Commentary: The transition to " Push Streams " has no preceding mention of server push . This adds a reference to the correct section of RFC7540 . 
 If mention of server push is desired before mention of push stream , would it be simpler to move the final sentence of the paragraph to the start ? 
 Maybe this would be better if section 4 was moved after section 6 ? Then the concepts would be explained before going into the framing . I 'd also like to reorder / renumber all the push frame types so they 're all adjacent to one another and in a sensible order . Is there a reason they 're numbered as they are ? If not , I 'll open an issue to renumber them . 
 There 's already an issue to reorder some of the sections , so I 'm happy to consider this as part of the same discussion . As to the numbering , the primary reason is maintaining the same frame IDs for things that stayed over from HTTP/2 -- PUSHPROMISE has the same ID , CANCELPUSH has the ID that HTTP/2 used for RSTSTREAM , and DUPLICATEPUSH is brand new and so pushes into unallocated space . 
 Given that is in now , do you still see this as a problem ? 
 I think the Server Push section still lacks a simple explanation of what the push does . A sentence like what I in this PR at the beginning would help that . Currently the Server Push section goes directly into mechanics . " HTTP/3 server push is similar to what is described in HTTP/2 { { ! HTTP2 } } , but uses different mechanisms . Each server push is identified by a unique  ID . ... " I 'd add more to the first paragraph in case people do n't want to read the H2 draft . 
 I think I 'd prefer for the reference to be to 4.4 of the current draft instead , since that does point to RFC7540 and has more context as well . 
 Whoops -- which also does n't have the two - sentence explanation of what push is . That 's up in the intro . Let me copy that over to 4.4 . 
 Thanks for the text  , it looks great . I 'm happy with this , so it 's up to you to decide when this is ready to merge .
Paragraph (version A):
HTTP/3 server push is similar to what is described in HTTP/2 HTTP2,
but uses different mechanisms.
Paragraph (version B):
Server push is an interaction mode introduced in HTTP/2 HTTP2 which
permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request.  This trades
off network usage against a potential latency gain.  HTTP/3 server
push is similar to what is described in HTTP/2 HTTP2, but uses
different mechanisms.
Paragraph (version B):
Server push is an optional feature introduced in HTTP/2 that allows a
server to initiate a response before a request has been made.  See
server-push for more details.
Draft: draft-ietf-quic-transport

Commentary: This was suggested for , but never got merged .
Paragraph (version A):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  Stream IDs are unique to a stream.  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.  Stream
IDs are encoded as variable-length integers (see integer-encoding).
Paragraph (version B):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection.  Stream IDs
are encoded as variable-length integers (see integer-encoding).  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.
Draft: draft-ietf-quic-recovery

Commentary: No need to padd the PADDDING with addditional D 's . 
 Thanks !
Paragraph (version A):
Because the server could be blocked until more packets are received,
the client MUST ensure that the crypto retransmission timer is set if
there is unacknowledged crypto data or if the client does not yet
have 1-RTT keys.  If the crypto retransmission timer expires before
the client has 1-RTT keys, it is possible that the client may not
have any crypto data to retransmit.  However, the client MUST send a
new packet, containing only PING or PADDDING frames if necessary, to
allow the server to continue sending data.  If Handshake keys are
available to the client, it MUST send a Handshake packet, and
otherwise it MUST send an Initial packet in a UDP datagram of at
least 1200 bytes.
Paragraph (version B):
Because the server could be blocked until more packets are received,
the client MUST ensure that the crypto retransmission timer is set if
there is unacknowledged crypto data or if the client does not yet
have 1-RTT keys.  If the crypto retransmission timer expires before
the client has 1-RTT keys, it is possible that the client may not
have any crypto data to retransmit.  However, the client MUST send a
new packet, containing only PING or PADDING frames if necessary, to
allow the server to continue sending data.  If Handshake keys are
available to the client, it MUST send a Handshake packet, and
otherwise it MUST send an Initial packet in a UDP datagram of at
least 1200 bytes.
Draft: draft-ietf-quic-http

Commentary: Makes two minor fixes in the GOAWAY text , both editorial : Correctly references the MAXSTREAMS frame instead of the MAXSTREAM_ID frame Notes that servers need not ( and can not ) send a GOAWAY if the client has used up all the possible stream IDs ; the client simply wo n't be making any more requests . 
 This is a whatever ...
Paragraph (version A):
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame.  Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC
MAX_STREAM_ID frame.
Paragraph (version B):
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame.  Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC
MAX_STREAMS frame.
Paragraph (version B):
If a client has consumed all available bidirectional stream IDs with
requests, the server need not send a GOAWAY frame, since the client
is unable to make further requests.
Draft: draft-ietf-quic-recovery

Commentary: This PR adds text and pseudo - code to clarify what an endpoint should do when PTO fires and there is no data or other ack - eliciting frames to send . 
 I 've done s / endpoint / sender . Let 's deal with this separately . On the SHOULD , thinking about this , yes , I think I agree with you . I 'll modify the PR , let 's see how that looks . 
 Ok , modified , take a look 
 As written now , this swaps a SHOULD and a MAY , so I 'm changing it to design . 
 As discussed with 6.2.2.2 is awkward , because in the first paragraph it says And then the very last paragraph changes that by saying What is super unclear is that the final paragraph apparently means to imply that when there is no new or unACKed data to send , nothing should be send , i.e. , it invalidates the SHOULD in the first paragraph . Related to that , the pseudo code still uses , which is also inaccurate , since it 's really " at least one ( unless you do n't have new or unACKed data ) but can also send two " . Good luck finding a good name for that function :-) 
 The pseudocode now uses SendOneOrTwoPackets ( ) , but the last paragraph pretty clearly violates the previous MUST , which is very bad . The simplest fix would be to change the MUST to a " SHOULD unless otherwise specified " , but I 'm increasingly thinking we should stick with the MUST and if you get into a situation you have nothing to send , require sending something ack - eliciting to ensure in - flight packets are removed from flight . Thoughts ?
Paragraph (version A):
When a PTO timer expires, the sender MUST send one ack-eliciting
packet as a probe, unless there is nothing to send.  A sender MAY
send up to two ack-eliciting packets, to avoid an expensive
consecutive PTO expiration due to a single packet loss.
Paragraph (version B):
Alternatively, instead of sending an ack-eliciting packet, the sender
MAY mark any packets still in flight as lost.  Doing so avoids
sending an additional packet, but increases the risk that loss is
declared too aggressively, resulting in an unnecessary rate reduction
by the congestion controller.
Paragraph (version A):
When a PTO timer expires, new or previously-sent data may not be
available to send and packets may still be in flight.  A sender can
be blocked from sending new data in the future if packets are left in
flight.  Under these conditions, a sender SHOULD mark any packets
still in flight as lost.  If a sender wishes to establish delivery of
packets still in flight, it MAY send an ack-eliciting packet and re-
arm the PTO timer instead.
Draft: draft-ietf-quic-recovery

Commentary: Editorial fix for This seems like the minimal fix for the existing text , though I wonder if it 's the correct one . 
 I think this fix is fine , but it 's inadequate . I 'll take this in since it 's useful . 
 Can you clarify why it 's inadequate on the still open issue ? 
 primarily because it does not correct the pseudocode , but I 've also made some textual adjustments in 
 As discussed with 6.2.2.2 is awkward , because in the first paragraph it says And then the very last paragraph changes that by saying What is super unclear is that the final paragraph apparently means to imply that when there is no new or unACKed data to send , nothing should be send , i.e. , it invalidates the SHOULD in the first paragraph . Related to that , the pseudo code still uses , which is also inaccurate , since it 's really " at least one ( unless you do n't have new or unACKed data ) but can also send two " . Good luck finding a good name for that function :-) 
 The pseudocode now uses SendOneOrTwoPackets ( ) , but the last paragraph pretty clearly violates the previous MUST , which is very bad . The simplest fix would be to change the MUST to a " SHOULD unless otherwise specified " , but I 'm increasingly thinking we should stick with the MUST and if you get into a situation you have nothing to send , require sending something ack - eliciting to ensure in - flight packets are removed from flight . Thoughts ?
Paragraph (version A):
When a PTO timer expires, the sender MUST send one ack-eliciting
packet as a probe.  A sender MAY send up to two ack-eliciting
packets, to avoid an expensive consecutive PTO expiration due to a
single packet loss.
Paragraph (version B):
When a PTO timer expires, the sender MUST send one ack-eliciting
packet as a probe, unless there is nothing to send.  A sender MAY
send up to two ack-eliciting packets, to avoid an expensive
consecutive PTO expiration due to a single packet loss.
Draft: draft-ietf-quic-recovery

Commentary: Adds some explanation about why it 's better to arm / fire the time threshold alarm before the crypto retransmission timeout . Hopefully clarifies comments from 
 Thanks for the explanation . It 's much clearer . Can i ask for one more clarification ? In DetectLostPackets , should n't the for - loop have been something like this : 
 Thanks for catching the pseudocode error in DetectLostPackets . PTAL . 
 lgtm . thank you ! 
 In both SetLossDetectionTimer ( ) and OnLossDetectionTimeout ( ) , the losstime based timer setup and loss detection happens before the crypto loss recovery logics . That seems at the cross road with the idea that crypto packets having higher priority in loss recovery . In fact in OnLossDetectionTimerou ( ) , if losstime is present and we go into DetectLostPackets ( ) , then we will only decect loss of one packet number space between Initial and Handshake . Plus the losstime used to set the timer is the earliest among all possible values , which means even if only one of Initial and Handshake space has inflight packets , we may still not retransmit all the inflight packets when this timer fires . So this current code really does n't follow the idea that when crypto is inflight and loss timer fires , all inflight crypto needs to be retransmitted . If we change the code so that crypto is handled first , we can also reduce the states need to be maintained and simplify some of the functions . In current draft there are 3 losstimes , one per packet number space . By always handling crypto first , we will need such loss_time for AppData space only , and no need to have the helper function to GetEarliestLossTime ( ) . ( I 'm more than happy to cook up a PR if people think this makes sense . ) 
 It 's been a few days . I sent PR . 
 This was introduced as a fix to , and fixed in I do n't think we should revert that fix . 
 +1 to comment . Timers are necessary when you have no information about what might be lost , but if you do have information , there 's no reason not to use that instead . 
 I sent out an editorial PR to clarify why time based loss detection has higher priority .
Paragraph (version A):
The crypto retransmission timer is not set if the time threshold
time-threshold loss detection timer is set.  When the crypto
retransmission timer is active, the probe timer (pto) is not active.
Paragraph (version B):
The crypto retransmission timer is not set if the time threshold
time-threshold loss detection timer is set.  The time threshold loss
detection timer is expected to both expire earlier than the crypto
retransmission timeout and be less likely to spuriously retransmit
data.  The Initial and Handshake packet number spaces will typically
contain a small number of packets, so losses are less likely to be
detected using packet-threshold loss detection.
Paragraph (version B):
When the crypto retransmission timer is active, the probe timer (pto)
is not active.
Draft: draft-ietf-quic-transport

Commentary: The text here had a MUST prohibiting data+offset from exceeding 2 ^ 62 - 1 . But that is redundant with flow control , which ca n't express a limit greater than this anyway . So just point to FLOWCONTROLERROR . 
 Sec 19.8 says : The first byte in the stream has an offset of 0 . The largest offset delivered on a stream - the sum of the offset and data length - MUST be less than 2 ^ 62 . It certainly possible to express a STREAM frame that violates this rule . What action should we take ? 
 I do n't know if we ever wrote this down , but I think that we might say if you catch a peer violating the spec , then you can send an error of any type you like . But for this case , PROTOCOL_VIOLATION is entirely appropriate ( as with many others of this sort ) . 
 Not just offset , but offset + content size of stream frame , otherwise there is no fixed limit on stream sizes , which is unfortunate .
Paragraph (version A):
The first byte in the stream has an offset of 0.  The largest offset
delivered on a stream - the sum of the offset and data length - MUST
be less than 2^62.
Paragraph (version B):
The first byte in the stream has an offset of 0.  The largest offset
delivered on a stream - the sum of the offset and data length -
cannot exceed 2^62-1, as it is not possible to provide flow control
credit for that data.  Receipt of a frame that exceeds this limit
will be treated as a connection error of type FLOW_CONTROL_ERROR.
Draft: draft-ietf-quic-recovery

Commentary: PTO works out fine , but loss_delay becomes weird . We should probably handle that . 
 In some environments , Kerberos integration ( for server and client authentication ) might be preferable to authentication via server certificates and SPNEGO . 
 Outside of this WG charter . A version of QUIC could be defined which does this , hypothetically , but our charter is to use TLS as the handshake for the version of QUIC we define . 
 One small suggestion , but LG
Paragraph (version B):
An endpoint might consistently record RTT samples as 0 in extremely
low latency networks, leading to a smoothed_rtt of 0.  Consequently,
the endpoint could declare all earlier packets as lost immediately
upon receiving an acknowledgement for a later packet.  That is, the
endpoint would not provide any reordering tolerance.  To avoid
declaring packets as lost too early, the time threshold MUST be set
to at least kGranularity (defined in ld-consts-of-interest).
Draft: draft-ietf-quic-tls

Commentary: No point in levying requirements on them . 
 Section 8.2 says : However , this directly contradicts TLS 1.3 , which says : In order to say this , this document would need to Update 8446 , and even then it does n't make sense because the presumptive point of this rule is to detect attempts to negotiate QUIC with non - QUIC TLS endpoints , which do n't need to conform to this RFC ( and may predate it ) . 
 I do n't think QUIC can tell anyone what do with regard to any protocol that is not QUIC . And since QUIC v1 carries its own TLS record wrapping it makes even less sense . 
 I agree with the problem statement , however I wonder if this opens a session ticket obtained using TLS13 - over - TCP to be used in QUIC . Is that what we want ? 
 why would this text have an impact on that ? Could n't I negotiate TLS 1.3 over TCP w/o extension and then send the resume over QUIC w/ extension ? 
 The point here is to insist on the alert if the extension is understood . This was n't intended to supersede 8446 . 
 My bad . I was confused with the earlier versions of the QUIC - TLS draft that had the transport_parameters extension in the session tickets . 
 I think you could phrase that , but is it useful , given that we ca n't rely on it ? 
 Probably not . I 'm OK with culling the text . 
 This might not be possible if a cloud load balancer only forwards QUIC with TLS and terminates TLS otherwise .
Paragraph (version A):
Endpoints MUST NOT send this extension in a TLS connection that does
not use QUIC (such as the use of TLS with TCP defined in TLS13).  A
fatal unsupported_extension alert MUST be sent if this extension is
received when the transport is not QUIC.
Paragraph (version B):
Endpoints MUST NOT send this extension in a TLS connection that does
not use QUIC (such as the use of TLS with TCP defined in TLS13).  A
fatal unsupported_extension alert MUST be sent by an implementation
that supports this extension if the extension is received when the
transport is not QUIC.