Draft: draft-ietf-quic-recovery

Commentary: Addresses . 
 This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes : 5.3 : " These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [ QUIC - TRANSPORT ] . " This text implies that the computation of the delay is described in Section 19.3 of QUIC - TRANSPORT . However , I do n't think it is described the calculation , only the definition of the field . Please reformulate to imply only field definition not calculation . 5.3 : " On the first RTT sample for the network path , that sample is used as rttsample . This ensures that the first measurement erases the history of any persisted or default values . " I think this intended to cover cases where path changes are detected . But it is not well expressed . Does this need a reformulation and a reference into QUIC - TRANSPORT where it states when such a reset should occur ? 6.1 : " Either its packet number is kPacketThreshold smaller than an acknowledged packet " Nitpicking , assuming no PN gaps in transmission . Does that need a note ? 6.2.4 : " An endpoint MAY send up to two full - sized datagrams containing ack - eliciting packets , to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces . " This last part , I assume intended to generate additional datagrams to prevent single loss to impact . However , due to coalescing this is unclear in this context . 7 : " Endpoints can unilaterally choose a different algorithm to use , such as  ( [ RFC8312 ] ) . " I think this sentence should be explicit that in needs to be sender - based algorithms . I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it . 7.2 : " Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size ( maxdatagramsize ) , limited to the larger of bytes or twice the maximum datagram size . " " maximum datagram size " is not used in Transport there need to be alignment here of what name to use . Transport has Maximum Packet Size , which appears to match the definition in the appendix of maxdatagram_size . 
 Thanks for your careful review , -- these are good finds ! I 've addressed your comments below and in . I 'll address point 6 in a separate PR . 19.3 has the following text , which does tell how to compute acknowledgement delay from the ACK Delay field : I 've replaced " computed " with " decoded " in the recovery document to make it clearer . applies to packets , not to datagrams . We 've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing . I think the text is pretty clear on this : " An endpoint MAY send up to two full - sized datagrams containing ack - eliciting packets " . ' ve " sender - side " to make the controller more explicit . To your point about making this a sender requirement , that is covered in the transport doc ( end of ): 
 Based on and , labeling this as " editorial " 
 I think these issues are resolved once the two PRs are completely ready . 
 In Section 5.3 : " When there are no samples for a network path , and on the first RTT sample for the network path : smoothedrtt = rttsample rttvar = rttsample / 2 Before any RTT samples are available , the initial RTT is used as rttsample . On the first RTT sample for the network path , that sample is used as rttsample . This ensures that the first measurement erases the history of any persisted or default values . " First of all this text uses " rttsample " while other places with the exception of the pseudo code uses latestrtt variable . There are two issues with that . First that the value of rttsample is state dependent . If there exist an latestrtt then that is used , if not the initial rtt . As the initial RTT is defined in Section 6.2.2 I think a forward reference is in place . Finally , should this calculation in cases where latestrtt exists be using minackdelay ? 
 I like to add that there are some structural issues in Section 6.2.1 and 6.2.2 where the initial value depends on both section . 
 Based on , labeling this as " editorial " 
 The PR resolves this issue . 
 OK , thanks GitHub for saving and duplicating my comments ... Looks good and appear to resolve the uncertainties I had .
Paragraph (version B):
The calculation of smoothed_rtt uses RTT samples after adjusting them
for acknowledgement delays.  These delays are decoded from the ACK
Delay field of ACK frames as described in Section 19.3 of QUIC-
TRANSPORT.
Paragraph (version A):
smoothed_rtt and rttvar are computed as follows, similar to RFC6298.
Paragraph (version A):
Before any RTT samples are available, the initial RTT is used as
rtt_sample.  On the first RTT sample for the network path, that
sample is used as rtt_sample.  This ensures that the first
measurement erases the history of any persisted or default values.
Paragraph (version B):
Similar to RFC6298, smoothed_rtt and rttvar are computed as follows.
Paragraph (version B):
An endpoint initializes the RTT estimator during connection
establishment and when the estimator is reset during connection
migration; see Section 9.4 of QUIC-TRANSPORT.  Before any RTT samples
are available for a new path or when the estimator is reset, the
estimator is initialized using the initial RTT; see pto-handshake.
Paragraph (version B):
RTT samples for the network path are recorded in latest_rtt; see
latest-rtt.  On the first RTT sample after initialization, the
estimator is reset using that sample.  This ensures that the
estimator retains no history of past samples.
Paragraph (version A):
Either its packet number is kPacketThreshold smaller than an
acknowledged packet (packet-threshold), or it was sent long enough
in the past (time-threshold).
Paragraph (version B):
The packet was sent kPacketThreshold packets before an
acknowledged packet (packet-threshold), or it was sent long enough
in the past (time-threshold).
Paragraph (version A):
This document specifies a congestion controller for QUIC similar to
TCP NewReno (RFC6582).
Paragraph (version A):
The signals QUIC provides for congestion control are generic and are
designed to support different algorithms.  Endpoints can unilaterally
choose a different algorithm to use, such as Cubic (RFC8312).
Paragraph (version A):
If an endpoint uses a different controller than that specified in
this document, the chosen controller MUST conform to the congestion
control guidelines specified in Section 3.1 of RFC8085.
Paragraph (version B):
This document specifies a sender-side congestion controller for QUIC
similar to TCP NewReno (RFC6582).
Paragraph (version B):
The signals QUIC provides for congestion control are generic and are
designed to support different sender-side algorithms.  A sender can
unilaterally choose a different algorithm to use, such as Cubic
(RFC8312).
Paragraph (version B):
If a sender uses a different controller than that specified in this
document, the chosen controller MUST conform to the congestion
control guidelines specified in Section 3.1 of RFC8085.