Draft: draft-ietf-quic-recovery

Commentary: Again , mostly nits . Lots of parentheses .
Paragraph (version A):
This design obviates the need for disambiguating between
transmissions and retransmissions and eliminates significant
complexity from QUIC's interpretation of TCP loss detection
mechanisms.
Paragraph (version B):
This design obviates the need for disambiguating between
transmissions and retransmissions; this eliminates significant
complexity from QUIC's interpretation of TCP loss detection
mechanisms.
Paragraph (version A):
Readers familiar with TCP's loss detection and congestion control
will find algorithms here that parallel well-known TCP ones.
Protocol differences between QUIC and TCP however contribute to
algorithmic differences.  We briefly describe these protocol
differences below.
Paragraph (version B):
Readers familiar with TCP's loss detection and congestion control
will find algorithms here that parallel well-known TCP ones.
However, protocol differences between QUIC and TCP contribute to
algorithmic differences.  These protocol differences are briefly
described below.
Paragraph (version A):
QUIC's packet number is strictly increasing within a packet number
space, and directly encodes transmission order.  A higher packet
number signifies that the packet was sent later, and a lower packet
number signifies that the packet was sent earlier.  When a packet
containing ack-eliciting frames is detected lost, QUIC rebundles
necessary frames in a new packet with a new packet number, removing
ambiguity about which packet is acknowledged when an ACK is received.
Consequently, more accurate RTT measurements can be made, spurious
retransmissions are trivially detected, and mechanisms such as Fast
Retransmit can be applied universally, based only on packet number.
Paragraph (version B):
QUIC's packet number is strictly increasing within a packet number
space, and directly encodes transmission order.  A higher packet
number signifies that the packet was sent later, and a lower packet
number signifies that the packet was sent earlier.  When a packet
containing ack-eliciting frames is detected lost, QUIC includes
necessary frames in a new packet with a new packet number, removing
ambiguity about which packet is acknowledged when an ACK is received.
Consequently, more accurate RTT measurements can be made, spurious
retransmissions are trivially detected, and mechanisms such as Fast
Retransmit can be applied universally, based only on packet number.
Paragraph (version A):
QUIC ACKs contain information that is similar to TCP SACK, but QUIC
does not allow any acked packet to be reneged, greatly simplifying
implementations on both sides and reducing memory pressure on the
sender.
Paragraph (version B):
QUIC ACKs contain information that is similar to TCP SACK, but QUIC
does not allow any acknowledged packet to be reneged, greatly
simplifying implementations on both sides and reducing memory
pressure on the sender.
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):
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):
An RTT sample is generated using only the largest acknowledged packet
in the received ACK frame.  This is because a peer reports ACK delays
for only the largest acknowledged packet in an ACK frame.  While the
reported ACK delay is not used by the RTT sample measurement, it is
used to adjust the RTT sample in subsequent computations of
smoothed_rtt and rttvar smoothed-rtt.
Paragraph (version B):
An RTT sample is generated using only the largest acknowledged packet
in the received ACK frame.  This is because a peer reports ACK delays
for only the largest acknowledged packet in an ACK frame.  While the
reported ACK delay is not used by the RTT sample measurement, it is
used to adjust the RTT sample in subsequent computations of
smoothed_rtt and rttvar (smoothed-rtt).
Paragraph (version A):
The RTT for a network path may change over time.  If a path's actual
RTT decreases, the min_rtt will adapt immediately on the first low
sample.  If the path's actual RTT increases, the min_rtt will not
adapt to it, allowing future RTT samples that are smaller than the
new RTT be included in smoothed_rtt.
Paragraph (version B):
The RTT for a network path may change over time.  If a path's actual
RTT decreases, the min_rtt will adapt immediately on the first low
sample.  If the path's actual RTT increases, the min_rtt will not
adapt to it, allowing future RTT samples that are smaller than the
new RTT to be included in smoothed_rtt.
Paragraph (version A):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for acknowledgement delays.  These delays are computed using
the ACK Delay field of the ACK frame as described in Section 19.3 of
QUIC-TRANSPORT.  For packets sent in the ApplicationData packet
number space, a peer limits any delay in sending an acknowledgement
for an ack-eliciting packet to no greater than the value it
advertised in the max_ack_delay transport parameter.  Consequently,
when a peer reports an Ack Delay that is greater than its
max_ack_delay, the delay is attributed to reasons out of the peer's
control, such as scheduler latency at the peer or loss of previous
ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
Paragraph (version B):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for acknowledgement delays.  These delays are computed using
the ACK Delay field of the ACK frame as described in Section 19.3 of
QUIC-TRANSPORT.  For packets sent in the Application Data packet
number space, a peer limits any delay in sending an acknowledgement
for an ack-eliciting packet to no greater than the value it
advertised in the max_ack_delay transport parameter.  Consequently,
when a peer reports an Ack Delay that is greater than its
max_ack_delay, the delay is attributed to reasons out of the peer's
control, such as scheduler latency at the peer or loss of previous
ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
Paragraph (version A):
Acknowledgement-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):
Acknowledgement-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 A):
The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection RFC5681 RFC6675.  Implementations SHOULD NOT use a packet
threshold less than 3, to keep in line with TCP RFC5681.
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 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):
The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection (RFC5681, RFC6675).  In order to remain similar to TCP,
implementations SHOULD NOT use a packet threshold less than 3; see
RFC5681.
Paragraph (version B):
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 A):
As with loss detection, the probe timeout is per packet number space.
The PTO algorithm used in QUIC implements the reliability functions
of Tail Loss Probe RACK, RTO RFC5681, and F-RTO algorithms for TCP
RFC5682.  The timeout computation is based on TCP's retransmission
timeout period RFC6298.
Paragraph (version B):
As with loss detection, the probe timeout is per packet number space.
The PTO algorithm used in QUIC implements the reliability functions
of Tail Loss Probe (RACK), RTO (RFC5681), and F-RTO (RFC5682)
algorithms for TCP.  The timeout computation is based on TCP's
retransmission timeout period (RFC6298).
Paragraph (version A):
The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet.  This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variation in the
estimate (4*rttvar), and max_ack_delay, to account for the maximum
time by which a receiver might delay sending an acknowledgement.
When the PTO is armed for Initial or Handshake packet number spaces,
the max_ack_delay is 0, as specified in 13.2.1 of QUIC-TRANSPORT.
Paragraph (version B):
The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet.  This time period includes the
estimated network round-trip time (smoothed_rtt), the variation in
the estimate (4*rttvar), and max_ack_delay, to account for the
maximum time by which a receiver might delay sending an
acknowledgement.  When the PTO is armed for Initial or Handshake
packet number spaces, the max_ack_delay is 0, as specified in 13.2.1
of QUIC-TRANSPORT.
Paragraph (version A):
When ack-eliciting packets in multiple packet number spaces are in
flight, the timer MUST be set for the packet number space with the
earliest timeout, with one exception.  The ApplicationData packet
number space (Section 4.1.1 of QUIC-TLS) MUST be ignored until the
handshake completes.  Not arming the PTO for ApplicationData prevents
a client from retransmitting a 0-RTT packet on a PTO expiration
before confirming that the server is able to decrypt 0-RTT packets,
and prevents a server from sending a 1-RTT packet on a PTO expiration
before it has the keys to process an acknowledgement.
Paragraph (version B):
When ack-eliciting packets in multiple packet number spaces are in
flight, the timer MUST be set for the packet number space with the
earliest timeout, with one exception.  The Application Data packet
number space (Section 4.1.1 of QUIC-TLS) MUST be ignored until the
handshake completes.  Not arming the PTO for Application Data
prevents a client from retransmitting a 0-RTT packet on a PTO
expiration before confirming that the server is able to decrypt 0-RTT
packets, and prevents a server from sending a 1-RTT packet on a PTO
expiration before it has the keys to process an acknowledgement.
Paragraph (version A):
The probe timer MUST NOT be set if the time threshold time-threshold
loss detection timer is set.  The time threshold loss detection timer
is expected to both expire earlier than the PTO and be less likely to
spuriously retransmit data.
Paragraph (version B):
The probe timer MUST NOT be set if the time threshold (time-
threshold) loss detection timer is set.  The time threshold loss
detection timer is expected to both expire earlier than the PTO and
be less likely to spuriously retransmit data.
Paragraph (version A):
Since the server could be blocked until more packets 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
acknowledgement for one of its Handshake or 1-RTT packets, and has
not received a HANDSHAKE_DONE frame.  If Handshake keys are available
to the client, it MUST send a Handshake packet, and otherwise it MUST
send an Initial packet in a UDP datagram 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
acknowledgement for one of its Handshake or 1-RTT packets, and has
not received a HANDSHAKE_DONE frame.  If Handshake keys are available
to the client, it MUST send a Handshake packet, and otherwise it MUST
send an Initial packet in a UDP datagram of at least 1200 bytes.
Paragraph (version A):
To speed up handshake completion under these conditions, an endpoint
MAY send a packet containing unacknowledged CRYPTO data earlier than
the PTO expiry, subject to address validation limits; see Section 8.1
of QUIC-TRANSPORT.
Paragraph (version B):
To speed up handshake completion under these conditions, an endpoint
MAY 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.
Paragraph (version A):
In addition to sending data in the packet number space for which the
timer expired, the sender SHOULD send ack-eliciting packets from
other packet number spaces with in-flight data, coalescing packets if
possible.  This is particularly valuable when the server has both
Initial and Handshake data in-flight or the client has both Handshake
and ApplicationData in-flight, because the peer might only have
receive keys for one of the two packet number spaces.
Paragraph (version B):
In addition to sending data in the packet number space for which the
timer expired, the sender SHOULD send ack-eliciting packets from
other packet number spaces with in-flight data, coalescing packets if
possible.  This is particularly valuable when the server has both
Initial and Handshake data in-flight or the client has both Handshake
and Application Data in-flight, because the peer might only have
receive keys for one of the two packet number spaces.
Paragraph (version A):
It is expected that keys are discarded after packets encrypted with
them would be acknowledged or declared lost.  Initial secrets however
might be discarded sooner, as soon as handshake keys are available;
see Section 4.11.1 of QUIC-TLS.
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 B):
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.11.1 of QUIC-TLS.
Paragraph (version B):
This document specifies a 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 algorithms.  Endpoints can unilaterally
choose a different algorithm to use, such as Cubic (RFC8312).
Paragraph (version A):
If a path has been verified to support ECN RFC3168 RFC8311, QUIC
treats a Congestion Experienced (CE) codepoint in the IP header as a
signal of congestion.  This document specifies an endpoint's response
when its peer receives packets with the ECN-CE codepoint.
Paragraph (version B):
If a path has been verified to support ECN (RFC3168, RFC8311), QUIC
treats a Congestion Experienced (CE) codepoint in the IP header as a
signal of congestion.  This document specifies an endpoint's response
when its peer receives packets with the ECN-CE codepoint.
Paragraph (version A):
When an ACK frame is received that establishes loss of all in-flight
packets sent over a long enough period of time, the network is
considered to be experiencing persistent congestion.  Commonly, this
can be established by consecutive PTOs, but since the PTO timer is
reset when a new ack-eliciting packet is sent, an explicit duration
must be used to account for those cases where PTOs do not occur or
are substantially delayed.  The rationale for this threshold is to
enable a sender to use initial PTOs for aggressive probing, as TCP
does with Tail Loss Probe (TLP) RACK, before establishing persistent
congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681.
The RECOMMENDED value for kPersistentCongestionThreshold is 3, which
is approximately equivalent to two TLPs before an RTO in TCP.
Paragraph (version B):
When an ACK frame is received that establishes loss of all in-flight
packets sent over a long enough period of time, the network is
considered to be experiencing persistent congestion.  Commonly, this
can be established by consecutive PTOs, but since the PTO timer is
reset when a new ack-eliciting packet is sent, an explicit duration
must be used to account for those cases where PTOs do not occur or
are substantially delayed.  The rationale for this threshold is to
enable a sender to use initial PTOs for aggressive probing, as TCP
does with Tail Loss Probe (TLP; see RACK), before establishing
persistent congestion, as TCP does with a Retransmission Timeout
(RTO; see RFC5681).  The RECOMMENDED value for
kPersistentCongestionThreshold is 3, which is approximately
equivalent to two TLPs before an RTO in TCP.
Paragraph (version A):
When persistent congestion is established, the sender's congestion
window MUST be reduced to the minimum congestion window
(kMinimumWindow).  This response of collapsing the congestion window
on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail
Loss Probes (TLP) RACK.
Paragraph (version B):
When persistent congestion is established, the sender's congestion
window MUST be reduced to the minimum congestion window
(kMinimumWindow).  This response of collapsing the congestion window
on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP (RFC5681) after
Tail Loss Probes (TLP; see RACK).
Paragraph (version A):
Endpoints choose the congestion controller that they use.  Though
congestion controllers generally treat reports of ECN-CE markings as
equivalent to loss RFC8311, the exact response for each controller
could be different.  Failure to correctly respond to information
about ECN markings is therefore difficult to detect.
Paragraph (version B):
Endpoints choose the congestion controller that they use.  Though
congestion controllers generally treat reports of ECN-CE markings as
equivalent to loss (RFC8311), the exact response for each controller
could be different.  Failure to correctly respond to information
about ECN markings is therefore difficult to detect.