Draft: draft-ietf-quic-recovery

Commentary: Also clarifies the implications of ignoring ackdelay when it would result in an RTT sample less than minrtt . 
 From , had the following suggestion for restructuring the RTT estimation section : 
 Does this mean that you cap the ACK Delay field to the value from the maxackdelay transport parameter with min ( ) ? That 's what the pseudocode says , but " limit " is sufficiently vague that I was n't sure . Especially since that has the effect of feeding massively inflated RTT samples into the estimator . ACK Delay will be large if the packet contains retransmissions . Should n't we be throwing out these samples rather than distorting them ? I mean , that was my understanding of the outcome of , and it seems like this case is rare enough that it wo n't starve the RTT estimator too badly . I think that this means that the RTT calculation should be done with an ACK Delay of 0 . 
 On your first point , this was an outcome of . Yes , it is a min , as the pseudocode says . For context , when was being discussed , two things were true that are n't anymore : ( i ) non - ack - eliciting packets were being used for the RTT computation , and ( ii ) we were using max(observed ackdelays ) as the maxackdelay . We 've since replaced that computation with the peer 's explicitly stated maxackdelay in our RTO computations . So if you do get inflated ack delays , that 's going to be because acks were being lost or the receiver took too long to send an ack . In either case , we want to capture the resulting increase somewhere , since the RTO should incorporate such potential delays . In , we decided to let the smoothedRTT EWMA estimator handle it . If it 's rare , it should n't move the EWMA by much . If it 's not rare , then the EWMA will capture it , and we will appropriately end up with a larger RTO . On your second point , yes , ack delay of 0 is what is meant there . Should there be more text ? 
 Well , if I understand the first , you are saying that RTO wo n't be negatively affected by this . But I 'm concerned about RTT . Excluding non - ack - eliciting packets changes the odds of encountering this , but that 's all . I lost track in . There were pictures of inscrutable graphs . What I think I will request here is text explaining the consequences of these tweaks . Clearer text . The text on the second just needs to be clearer . 
 That 's fair . I think we should add text to explain the consequences . 
 Meta - level comments . The code and text look fine .
Paragraph (version A):
When RTT is calculated, the ack delay field from the ACK frame SHOULD
be limited to the max_ack_delay specified by the peer.  Limiting
ack_delay to max_ack_delay ensures a peer specifying an extremely
small max_ack_delay doesn't cause more spurious timeouts than a peer
that correctly specifies max_ack_delay.  It SHOULD be subtracted from
the RTT as long as the result is larger than the min_rtt.  If the
result is smaller than the min_rtt, the RTT should be used, but the
ack delay field should be ignored.
Paragraph (version A):
A sender calculates both smoothed RTT (SRTT) and RTT variance
(RTTVAR) similar to those specified in RFC6298, see on-ack-received.
Paragraph (version A):
A sender takes an RTT sample when an ACK frame is received that
acknowledges a larger packet number than before (see on-ack-
received).  A sender will take multiple RTT samples per RTT when
multiple such ACK frames are received within an RTT.  When multiple
samples are generated within an RTT, the smoothed RTT and RTT
variance could retain inadequate history, as suggested in RFC6298.
Changing these computations is currently an open research question.
Paragraph (version B):
When RTT is calculated, the ack delay field from the ACK frame SHOULD
be limited to the max_ack_delay specified by the peer by using a
minimum of the two values.  Limiting ack_delay to max_ack_delay
ensures a peer specifying an extremely small max_ack_delay doesn't
cause more spurious timeouts than a peer that correctly specifies
max_ack_delay.  It SHOULD be subtracted from the RTT as long as the
result is larger than the min_rtt.  If the result is smaller than the
min_rtt, the RTT should be used, but the ack delay field should be
ignored.  Ignoring ack_delay when it would cause an RTT sample
smaller than the current min_rtt prevents a peer from manipulating
RTT samples below min_rtt at the cost of inflated RTT samples in the
presence of persistent delayed acks.
Paragraph (version B):
A sender takes an RTT sample when an ACK frame is received that
acknowledges a larger packet number than before.  A sender will take
multiple RTT samples per RTT when multiple such ACK frames are
received within an RTT.  When multiple samples are generated within
an RTT, the smoothed RTT and RTT variance could retain inadequate
history, as suggested in RFC6298.  Changing these computations is
currently an open research question.
Paragraph (version B):
A sender calculates both smoothed RTT (SRTT) and RTT variance
(RTTVAR) similar to those specified in RFC6298.  Note that computing
smoothed_rtt does not use ack_delay for the first RTT sample, because
doing so would result in a smoothed_rtt that is smaller than the
min_rtt.