Draft: draft-ietf-quic-recovery

Commentary: and part of 
   said : 
 said : 
 Good point , also 4.7 currently has TLP in the title , but does n't use it anywhere else in the section , so I 'll add some text on TLP too . 
 Please also update the RACK reference to version 14 . draft - ietf - tcpm - rack-14 
 The version update is part of the toolchain we use , so the newest version of RACK should be referenced automatically .
Paragraph (version A):
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
acknowledgment 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):
In doing this, QUIC avoids unnecessary congestion window reductions,
obviating the need for correcting mechanisms such as F-RTO (RFC5682).
Since QUIC does not collapse the congestion window on a PTO
expiration, a QUIC sender is not limited from sending more in-flight
packets after a PTO expiration if it still has available congestion
window.  This occurs when a sender is application-limited and the PTO
timer expires.  This is more aggressive than TCP's RTO mechanism when
application-limited, but identical when not application-limited.
Paragraph (version B):
QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's
RTO computation; see RFC6297.  QUIC's PTO includes the peer's maximum
expected acknowledgment delay instead of using a fixed minimum
timeout.
Paragraph (version B):
Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC
does not collapse the congestion window when the PTO expires, since a
single packet loss at the tail does not indicate persistent
congestion.  Instead, QUIC collapses the congestion window when
persistent congestion is declared; see persistent-congestion.  In
doing this, QUIC avoids unnecessary congestion window reductions,
obviating the need for correcting mechanisms such as F-RTO (RFC5682).
Since QUIC does not collapse the congestion window on a PTO
expiration, a QUIC sender is not limited from sending more in-flight
packets after a PTO expiration if it still has available congestion
window.  This occurs when a sender is application-limited and the PTO
timer expires.  This is more aggressive than TCP's RTO mechanism when
application-limited, but identical when not application-limited.
Paragraph (version A):
A single packet loss at the tail does not indicate persistent
congestion, so QUIC specifies a time-based definition to ensure one
or more packets are sent prior to a dramatic decrease in congestion
window; see persistent-congestion.
Paragraph (version B):
QUIC allows probe packets to temporarily exceed the congestion window
whenever the timer expires.
Paragraph (version A):
Acknowledgment-based loss detection implements the spirit of TCP's
Fast Retransmit (RFC5681), Early Retransmit (RFC5827), FACK (FACK),
SACK loss recovery (RFC6675), and RACK (RACK).  This section provides
an overview of how these algorithms are implemented in QUIC.
Paragraph (version B):
Acknowledgment-based loss detection implements the spirit of TCP's
Fast Retransmit (RFC5681), Early Retransmit (RFC5827), FACK (FACK),
SACK loss recovery (RFC6675), and RACK-TLP (RACK).  This section
provides an overview of how these algorithms are implemented in QUIC.