Draft: draft-ietf-quic-recovery

Commentary: From , minus the question of limiting bursts , which is in Issue Section 2 " are not acknowledged , declared lost , or abandoned along with old keys . " --are not acknowledged , declared lost , or discarded along with old keys . " Discarding is the term used in the rest of the doc notably in section 2.4 . I see some reference to " abandon packets " in the transport draft as well . Would be good to use the same term for consistency everywhere . Section 4.4 . " does not allow any acked packet to be reneged " --"does not allow any acknowledged packet to be reneged " Section 4.7 " QUIC uses a probe timeout ( see Section 6.2 ) , " --"QUIC uses a Probe Timeout ( PTO ) ( see Section 6.2 ) , " Section 5.2 " If the path 's actual RTT increases , the minrtt will not adapt to it , allowing future RTT samples that are smaller than the new RTT be included in smoothedrtt . " Would it safer to reset minrtt after persistent congestion is declared . This is important so we can adapt to a consistent spike in RTT as a result of a path change . Section 6.1.1 " Algorithms that increase the reordering threshold after spuriously detecting losses , such as TCP - NCR [ RFC4653 ] , have proven to be useful in TCP and are expected to at least as useful in QUIC . " It might be better to refer to RACK here which has an optional feature to increase reorder threshold in time . I do n't know of any major implementations that do TCP - NCR but maybe I am mistaken . Section 6.2.1 " time threshold Section 6.1.2 " --time threshold ( Section 6.1.2 ) “ The life of a connection that is experiencing consecutive PTOs is limited by the endpoint 's idle timeout . ” Is there any specification of recommended values for idle timeout ? Any values lower than 9 seconds could adversely impact preserving of connectivity during VM live migration . Section 6.2.4 " If the sender wants to elicit a faster acknowledgement on PTO , it can skip a packet number to eliminate the ack delay . " This adds some unnecessary complexity . Given that endpoint MAY send two full - sized datagrams , is n't that a better technique than skipping packet numbers ? Section 7.8 " The congestion period is calculated as the time between the oldest and newest lost packets : ( 3 - 0 ) = 3 . " --"The congestion period is calculated as the sent time difference between the oldest and newest lost packets : ( 3 - 0 ) = 3 . " It might be worth noting that persistent congestion can be declared without sending a PTO . Particularly because the example assumes PTOs . In the case where app kept on periodically sending new data and no ACKs came back for the threshold and then an ACK came back and declared all packets sent before it as lost . Section 8.2 " Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information . " A reminder should be here that PADDING counts towards in - flight so there is a possible impact on performance . Section B.8 The function AreAllPacketsLost does not have any pseudocode . 
 The last item is pointed out in . As I wrote in , suggested an example implementation . If you think it is reasonable , I will make a PR . 
 I 've addressed the editorial bits in . The rest are addressed below . We do n't have a recommended value for  timeout , but it the states the following : That said , the peer 's is known to both sides . If you find that the peer 's timeout is too short for your purposes , you can keep the connection alive through PINGs . On faster acknowledgement when PTO : yes , sending two packets works just fine . Skipping packet numbers is not something you need to do -- so the additional complexity concern is only for those who want to go do it -- it 's just something that an implementation can do to get an immediate ack anytime in the connection . On PTOs and persistent congestion , there 's text at the top of the section that calls this out explicitly : Nevertheless , I 've a sentence at the end of the example description . AreAllPacketsLost is in . 
 Marking this editorial , since the design one moved out . 
 One suggestion
Paragraph (version A):
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 abandoned along with old keys.
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):
QUIC uses a probe timeout (see pto), with a timer based on TCP's RTO
computation.  QUIC's PTO includes the peer's maximum expected
acknowledgement delay instead of using a fixed minimum timeout.  QUIC
does not collapse the congestion window until persistent congestion
(persistent-congestion) is declared, unlike TCP, which collapses the
congestion window upon expiry of an RTO.  Instead of collapsing the
congestion window and declaring everything in-flight lost, QUIC
allows probe packets to temporarily exceed the congestion window
whenever the timer expires.
Paragraph (version B):
QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's
RTO computation.  QUIC's PTO includes the peer's maximum expected
acknowledgement delay instead of using a fixed minimum timeout.  QUIC
does not collapse the congestion window until persistent congestion
(persistent-congestion) is declared, unlike TCP, which collapses the
congestion window upon expiry of an RTO.  Instead of collapsing the
congestion window and declaring everything in-flight lost, QUIC
allows probe packets to temporarily exceed the congestion window
whenever the timer expires.
Paragraph (version A):
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 abandoning the frame.  For more information, see Section 13.3 of
QUIC-TRANSPORT.
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 A):
Some networks may exhibit higher degrees of reordering, causing a
sender to detect spurious losses.  Algorithms that increase the
reordering threshold after spuriously detecting losses, such as TCP-
NCR (RFC4653), have proven to be useful in TCP and are expected to be
at least as useful in QUIC.  Re-ordering could be more common with
QUIC than TCP, because network elements cannot observe and fix the
order of out-of-order packets.
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 it with 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 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.
Paragraph (version B):
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.  To
reduce leaked information, endpoints can bundle acknowledgments with
other frames, or they can use PADDING frames at a potential cost to
performance.