Draft: draft-ietf-quic-recovery

Commentary: This should 
 I agree with The spec is clear . I have dropped the second commit . 
 Gentle ping 
 I think that I am still confused . In recovery , is used in three places : RTT calculation PTO calculation Persistent congestion Sec 18.2 of transport says that is default to 25ms and updated if a peer specifies the TP . Sec 13.2.1 of transport says there is a special rule : " For Initial and Handshake packets , a maxackdelay of 0 is used . " According to the context , this rule is applied to both RTT calculation and PTO calculation . In the pseudocode of recovery , is set to 0 initially . But I think that 25ms should be used for persistent congestion . The special rule is use for PTO calculation , which is good . But RTT calculation just depends on the initial value of 0 . Is n't it necessary to consider packet number space ? 
 Nice catch regarding inconsistencies . Maybe this is the only error that we have ? I think it might be a good idea to remove this initialization from the pseudo code , and within the definition of at , add a reference to the Transport Parameter definition in the transport doc . 
 Agreed . suggested a good text . I 'm planning to adopt it . It seems to me that you assume that the calculation of smooth RTT in the pseudocode is correct . If it is correct , I think  13.2.1 of transport should say that the special rule is only applied to RTO calculation , not to RTT calculation . 
 I think that the pseudo code gives you what the transport draft says . When processing an Initial or a Handshake packet , being passed to the UpdateRtt function of the pseudo code is always set to zero . That effectively eliminates the side effect caused by a non - zero . 
 OK . I understand . But honestly , it is difficult at least for me to understand the intention of the pseudocode . If had a guard clause where is set to 0 if the packet space is Initial or Handshake , it would much help . But this function does not take the packet space as argument , sigh . 
 I updated this PR . Please review this again . 
 I 'd like to merge this , ; can you fix the conflicts ? 
 Resolved :) 
 Thanks . I think that it 's turn now . 
 The spec says that 0 should be used for in and . In pseudo code , is used at three places . In , non - zero value of is used for and , which should be fixed . Other two places looks good . 
 LGTM modulo the grammatical point below .
Paragraph (version A):
Packets that contain ack-eliciting frames elicit an ACK from the
receiver within the maximum ack delay and are called ack-eliciting
packets.
Paragraph (version B):
Packets that contain ack-eliciting frames elicit an ACK from the
receiver within the maximum acknowledgement delay and are called
ack-eliciting packets.
Paragraph (version B):
Packets are considered in-flight when they are ack-eliciting or
contain a PADDING frame, and they have been sent but are not
acknowledged, declared lost, or discarded along with old keys.
Paragraph (version A):
An RTT sample is generated using only the largest acknowledged packet
in the received ACK frame.  This is because a peer reports ACK delays
for only the largest acknowledged packet in an ACK frame.  While the
reported ACK delay is not used by the RTT sample measurement, it is
used to adjust the RTT sample in subsequent computations of
smoothed_rtt and rttvar (smoothed-rtt).
Paragraph (version B):
An RTT sample is generated using only the largest acknowledged packet
in the received ACK frame.  This is because a peer reports
acknowledgment delays for only the largest acknowledged packet in an
ACK frame.  While the reported acknowledgment delay is not used by
the RTT sample measurement, it is used to adjust the RTT sample in
subsequent computations of smoothed_rtt and rttvar (smoothed-rtt).
Paragraph (version B):
An endpoint uses only locally observed times in computing the min_rtt
and does not adjust for acknowledgment delays reported by the peer.
Doing so allows the endpoint to set a lower bound for the
smoothed_rtt based entirely on what it observes (see smoothed-rtt),
and limits potential underestimation due to erroneously-reported
delays by the peer.
Paragraph (version A):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for acknowledgement delays.  These delays are computed using
the ACK Delay field of the ACK frame as described in Section 19.3 of
QUIC-TRANSPORT.  For packets sent in the Application Data packet
number space, a peer limits any delay in sending an acknowledgement
for an ack-eliciting packet to no greater than the value it
advertised in the max_ack_delay transport parameter.  Consequently,
when a peer reports an Ack Delay that is greater than its
max_ack_delay, the delay is attributed to reasons out of the peer's
control, such as scheduler latency at the peer or loss of previous
ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
Paragraph (version B):
If a packet is lost, the QUIC transport needs to recover from that
loss, such as by retransmitting the data, sending an updated frame,
or discarding the frame.  For more information, see Section 13.3 of
QUIC-TRANSPORT.
Paragraph (version B):
Some networks may exhibit higher degrees of packet reordering,
causing a sender to detect spurious losses.  Additionally, packet
reordering could be more common with QUIC than TCP, because network
elements that could observe and fix the order of reordered TCP
packets cannot do that for QUIC.  Algorithms that increase the
reordering threshold after spuriously detecting losses, such as RACK
RACK, have proven to be useful in TCP and are expected to at least as
useful in QUIC.
Paragraph (version B):
If the sender wants to elicit a faster acknowledgement on PTO, it can
skip a packet number to eliminate the acknowledgment delay.
Paragraph (version A):
When packet protection keys are discarded (see Section 4.10 of QUIC-
TLS), all packets that were sent with those keys can no longer be
acknowledged because their acknowledgements cannot be processed
anymore.  The sender MUST discard all recovery state associated with
those packets and MUST remove them from the count of bytes in flight.
Paragraph (version B):
When packet protection keys are discarded (see Section 4.8 of QUIC-
TLS), all packets that were sent with those keys can no longer be
acknowledged because their acknowledgements cannot be processed
anymore.  The sender MUST discard all recovery state associated with
those packets and MUST remove them from the count of bytes in flight.
Paragraph (version A):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  However, Initial
secrets are discarded as soon as handshake keys are proven to be
available to both client and server; see Section 4.11.1 of QUIC-TLS.
Paragraph (version B):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  However, Initial
secrets are discarded as soon as handshake keys are proven to be
available to both client and server; see Section 4.9.1 of QUIC-TLS.
Paragraph (version A):
Packets that carry only ACK frames can be heuristically identified by
observing packet size.  Acknowledgement patterns may expose
information about link characteristics or application behavior.
Endpoints can use PADDING frames or bundle acknowledgments with other
frames to reduce leaked information.