Draft: draft-ietf-quic-recovery

Commentary: I made some proposed tweaks in my local copy as I was doing my IESG review . There 's a couple places where I 'm not sure if it is actually editorial or the proposal actually changes the meaning ( and thus should be rejected ) .
Paragraph (version B):
All transmissions in QUIC are sent with a packet-level header, which
indicates the encryption level and includes a packet sequence number
(referred to below as a packet number).  The encryption level
indicates the packet number space, as described in Section 12.3 in
QUIC-TRANSPORT.  Packet numbers never repeat within a packet number
space for the lifetime of a connection.  Packet numbers are sent in
monotonically increasing order within a space, preventing ambiguity.
It is permitted for some packet numbers to never be used, leaving
intentional gaps.
Paragraph (version B):
QUIC ACK frames contain information similar to that in TCP Selective
Acknowledgements (SACKs, RFC2018).  However, QUIC does not allow a
packet acknowledgement to be reneged, greatly simplifying
implementations on both sides and reducing memory pressure on the
sender.
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 B):
QUIC allows probe packets to temporarily exceed the congestion window
whenever the timer expires.
Paragraph (version B):
At a high level, an endpoint measures the time from when a packet was
sent to when it is acknowledged as a round-trip time (RTT) sample.
The endpoint uses RTT samples and peer-reported host delays (see
Section 13.2 of QUIC-TRANSPORT) to generate a statistical description
of the network path's RTT.  An endpoint computes the following three
values for each path: the minimum value over a period of time
(min_rtt), an exponentially-weighted moving average (smoothed_rtt),
and the mean deviation (referred to as "variation" in the rest of
this document) in the observed RTT samples (rttvar).
Paragraph (version B):
min_rtt is the sender's estimate of the minimum RTT observed for a
given network path over a period of time.  In this document, min_rtt
is used by loss detection to reject implausibly small rtt samples.
Paragraph (version B):
smoothed_rtt is an exponentially-weighted moving average of an
endpoint's RTT samples, and rttvar estimates the variation in the RTT
samples using a mean variation.
Paragraph (version A):
The peer might report acknowledgment delays that are larger than the
peer's max_ack_delay during the handshake (Section 13.2.1 of QUIC-
TRANSPORT).  To account for this, the endpoint SHOULD ignore
max_ack_delay until the handshake is confirmed (Section 4.1.2 of
QUIC-TLS).  When they occur, these large acknowledgment delays are
likely to be non-repeating and limited to the handshake.  The
endpoint can therefore use them without limiting them to the
max_ack_delay, avoiding unnecessary inflation of the RTT estimate.
Paragraph (version A):
Note however that a large acknowledgment delay can result in a
substantially inflated smoothed_rtt, if there is either an error in
the peer's reporting of the acknowledgment delay or in the endpoint's
min_rtt estimate.  Therefore, prior to handshake confirmation, an
endpoint MAY ignore RTT samples if adjusting the RTT sample for
acknowledgment delay causes the sample to be less than the min_rtt.
Paragraph (version B):
The peer might report acknowledgment delays that are larger than the
peer's max_ack_delay during the handshake (Section 13.2.1 of QUIC-
TRANSPORT).  To account for this, the endpoint SHOULD ignore
max_ack_delay until the handshake is confirmed, as defined in
Section 4.1.2 of QUIC-TLS.  When they occur, these large
acknowledgment delays are likely to be non-repeating and limited to
the handshake.  The endpoint can therefore use them without limiting
them to the max_ack_delay, avoiding unnecessary inflation of the RTT
estimate.
Paragraph (version B):
Note that a large acknowledgment delay can result in a substantially
inflated smoothed_rtt, if there is either an error in the peer's
reporting of the acknowledgment delay or in the endpoint's min_rtt
estimate.  Therefore, prior to handshake confirmation, an endpoint
MAY ignore RTT samples if adjusting the RTT sample for acknowledgment
delay causes the sample to be less than the min_rtt.
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.
Paragraph (version B):
A sender SHOULD restart its PTO timer every time an ack-eliciting
packet is sent or acknowledged, or when Initial or Handshake keys are
discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always
set based on the latest estimate of the round-trip time and for the
correct packet across packet number spaces.
Paragraph (version A):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgment for one of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no
packets in flight.  When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an
Initial packet in a UDP datagram with a payload of at least 1200
bytes.
Paragraph (version B):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgment for any of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no
packets in flight.  When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an
Initial packet in a UDP datagram with a payload of at least 1200
bytes.
Paragraph (version A):
To speed up handshake completion under these conditions, an endpoint
MAY, for a limited number of occasions per each connection, send a
packet containing unacknowledged CRYPTO data earlier than the PTO
expiry, subject to the address validation limits in Section 8.1 of
QUIC-TRANSPORT.  Doing so at most once for each connection is
adequate to quickly recover from a single packet loss.  Endpoints
that do not cease retransmitting packets in response to
unauthenticated data risk creating an infinite exchange of packets.
Paragraph (version B):
To speed up handshake completion under these conditions, an endpoint
MAY, for a limited number of times per connection, send a packet
containing unacknowledged CRYPTO data earlier than the PTO expiry,
subject to the address validation limits in Section 8.1 of QUIC-
TRANSPORT.  Doing so at most once for each connection is adequate to
quickly recover from a single packet loss.  An endpoint that always
retransmits packets in response to receiving packets that it cannot
process risks creating an infinite exchange of packets.
Paragraph (version A):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet in the packet number space as a probe.  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.  All probe packets sent on a PTO MUST be ack-eliciting.
Paragraph (version B):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet in the packet number space as a probe.  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.  All probe packets sent on a PTO MUST be ack-eliciting.
Paragraph (version B):
An endpoint SHOULD include new data in packets that are sent on PTO
expiration.  Previously sent data MAY be sent if no new data can be
sent.  Implementations MAY use alternative strategies for determining
the content of probe packets, including sending new or retransmitted
data based on the application's priorities.
Paragraph (version A):
When packet protection keys are discarded (see Section 4.9 of QUIC-
TLS), all packets that were sent with those keys can no longer be
acknowledged because their acknowledgments 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 Initial and Handshake packet protection keys are discarded (see
Section 4.9 of QUIC-TLS), all packets that were sent with those keys
can no longer be acknowledged because their acknowledgments cannot be
processed.  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.9.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 and
Handshake secrets are discarded as soon as handshake and 1-RTT keys
are proven to be available to both client and server; see
Section 4.9.1 of QUIC-TLS.
Paragraph (version B):
Since network congestion is not affected by packet number spaces,
persistent congestion SHOULD consider packets sent across packet
number spaces.  A sender that does not have state for all packet
number spaces or an implementation that cannot compare send times
across packet number spaces MAY use state for just the packet number
space that was acknowledged.  This might result in erroneously
declaring persistent congestion, but it will not lead to a failure to
detect persistent congestion.
Paragraph (version A):
Congestion control fundamentally involves the consumption of signals
- both loss and ECN codepoints - from unauthenticated entities.  On-
path attackers can spoof or alter these signals.  An attacker can
cause endpoints to reduce their sending rate by dropping packets, or
alter send rate by changing ECN codepoints.