Draft: draft-ietf-quic-recovery

Commentary: Do I read this wrong , or did you go for acknowledgment contrary to the topic header ? 
 I was trained on something approximating British English , which generally uses the longer form . The title is a statement of ( subjective ) truth with no actual bearing on the changes . 
 In that case the capitalised ( capitalized ) version might also want to disagree with the topic header : " Acknowledgement " , assuming that US spelling is somewhat consistent . 
 There are other places with uppercase , but that needs a search , e.g. 
 Someone should learn to drive sed better . I 've fixed the uppercase variants as well . 
 No kidding , and acknowledgement is pretty long . I wonder if we should just define ' ack ' as acknowledgement at the beginning . 
 As " acknowledgment , " you mean . I prefer it with the ' e ' , but without is technically the American spelling . ( Although what I found said both occur everywhere ; the only difference is which is more prevalent . ) 
 The gift that keeps on giving ... 
 The English and US spelling forms are used arbitrarily in transport draft . 
 I think we can leave this for the RFC Editor to fix , unless for some reason we need to do a -34 anyway . Leaving this open until we know . 
 My guess is that there will be a -34 , based on past experience with the IESG . So it is better to fix it now . 
 couple of formatting ones , but otherwise lgtm . So it is
Paragraph (version A):
Packets that contain ack-eliciting frames elicit an ACK from the
receiver within the maximum acknowledgement delay and are called
ack-eliciting packets.
Paragraph (version B):
Packets that contain ack-eliciting frames elicit an ACK from the
receiver within the maximum acknowledgment delay and are called
ack-eliciting packets.
Paragraph (version A):
Long header packets that contain CRYPTO frames are critical to the
performance of the QUIC handshake and use shorter timers for
acknowledgement.
Paragraph (version B):
Long header packets that contain CRYPTO frames are critical to the
performance of the QUIC handshake and use shorter timers for
acknowledgment.
Paragraph (version A):
QUIC uses separate packet number spaces for each encryption level,
except 0-RTT and all generations of 1-RTT keys use the same packet
number space.  Separate packet number spaces ensures acknowledgement
of packets sent with one level of encryption will not cause spurious
retransmission of packets sent with a different encryption level.
Congestion control and round-trip time (RTT) measurement are unified
across packet number spaces.
Paragraph (version B):
QUIC uses separate packet number spaces for each encryption level,
except 0-RTT and all generations of 1-RTT keys use the same packet
number space.  Separate packet number spaces ensures acknowledgment
of packets sent with one level of encryption will not cause spurious
retransmission of packets sent with a different encryption level.
Congestion control and round-trip time (RTT) measurement are unified
across packet number spaces.
Paragraph (version A):
TCP uses a minimum congestion window of one packet.  However, loss of
that single packet means that the sender needs to waiting for a PTO
(pto) to recover, which can be much longer than a round-trip time.
Sending a single ack-eliciting packet also increases the chances of
incurring additional latency when a receiver delays its
acknowledgement.
Paragraph (version B):
TCP uses a minimum congestion window of one packet.  However, loss of
that single packet means that the sender needs to waiting for a PTO
(pto) to recover, which can be much longer than a round-trip time.
Sending a single ack-eliciting packet also increases the chances of
incurring additional latency when a receiver delays its
acknowledgment.
Paragraph (version A):
An RTT sample MUST NOT be generated on receiving an ACK frame that
does not newly acknowledge at least one ack-eliciting packet.  A peer
usually does not send an ACK frame when only non-ack-eliciting
packets are received.  Therefore an ACK frame that contains
acknowledgements for only non-ack-eliciting packets could include an
arbitrarily large ACK Delay value.  Ignoring such ACK frames avoids
complications in subsequent smoothed_rtt and rttvar computations.
Paragraph (version B):
An RTT sample MUST NOT be generated on receiving an ACK frame that
does not newly acknowledge at least one ack-eliciting packet.  A peer
usually does not send an ACK frame when only non-ack-eliciting
packets are received.  Therefore an ACK frame that contains
acknowledgments for only non-ack-eliciting packets could include an
arbitrarily large ACK Delay value.  Ignoring such ACK frames avoids
complications in subsequent smoothed_rtt and rttvar computations.
Paragraph (version B):
Endpoints MAY re-establish the min_rtt at other times in the
connection, such as when traffic volume is low and an acknowledgment
is received with a low acknowledgment delay.  Implementations SHOULD
NOT refresh the min_rtt value too often, since the actual minimum RTT
of the path is not frequently observable.
Paragraph (version A):
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):
After the handshake is confirmed, any acknowledgement delays reported
by the peer that are greater than the peer's max_ack_delay are
attributed to unintentional but potentially repeating delays, such as
scheduler latency at the peer or loss of previous acknowledgements.
Excess delays could also be due to a non-compliant receiver.
Therefore, these extra delays are considered effectively part of path
delay and incorporated into the RTT estimate.
Paragraph (version B):
The calculation of smoothed_rtt uses RTT samples after adjusting them
for acknowledgment delays.  These delays are decoded from the ACK
Delay field of ACK frames as described in Section 19.3 of QUIC-
TRANSPORT.
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 (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 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):
After the handshake is confirmed, any acknowledgment delays reported
by the peer that are greater than the peer's max_ack_delay are
attributed to unintentional but potentially repeating delays, such as
scheduler latency at the peer or loss of previous acknowledgments.
Excess delays could also be due to a non-compliant receiver.
Therefore, these extra delays are considered effectively part of path
delay and incorporated into the RTT estimate.
Paragraph (version B):
MUST NOT subtract the acknowledgment delay from the RTT sample if
the resulting value is smaller than the min_rtt.  This limits the
underestimation of the smoothed_rtt due to a misreporting peer.
Paragraph (version B):
Additionally, an endpoint might postpone the processing of
acknowledgments when the corresponding decryption keys are not
immediately available.  For example, a client might receive an
acknowledgment for a 0-RTT packet that it cannot decrypt because
1-RTT packet protection keys are not yet available to it.  In such
cases, an endpoint SHOULD subtract such local delays from its RTT
sample until the handshake is confirmed.
Paragraph (version A):
QUIC senders use acknowledgements to detect lost packets, and a probe
time out (see pto) to ensure acknowledgements are received.  This
section provides a description of these algorithms.
Paragraph (version B):
QUIC senders use acknowledgments to detect lost packets, and a probe
time out (see pto) to ensure acknowledgments are received.  This
section provides a description of these algorithms.
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):
The acknowledgment indicates that a packet sent later was delivered,
and the packet and time thresholds provide some tolerance for packet
reordering.
Paragraph (version A):
A Probe Timeout (PTO) triggers sending one or two probe datagrams
when ack-eliciting packets are not acknowledged within the expected
period of time or the server may not have validated the client's
address.  A PTO enables a connection to recover from loss of tail
packets or acknowledgements.
Paragraph (version A):
A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost.  When an
acknowledgement is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms; see ack-loss-detection.
Paragraph (version B):
A Probe Timeout (PTO) triggers sending one or two probe datagrams
when ack-eliciting packets are not acknowledged within the expected
period of time or the server may not have validated the client's
address.  A PTO enables a connection to recover from loss of tail
packets or acknowledgments.
Paragraph (version B):
A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost.  When an
acknowledgment is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms; see ack-loss-detection.
Paragraph (version B):
The PTO period is the amount of time that a sender ought to wait for
an acknowledgment 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 acknowledgment.
Paragraph (version B):
An endpoint MUST NOT set its PTO timer for the application data
packet number space until the handshake is confirmed.  Doing so
prevents the endpoint from retransmitting information in packets when
either the peer does not yet have the keys to process them or the
endpoint does not yet have the keys to process their acknowledgments.
For example, this can happen when a client sends 0-RTT packets to the
server; it does so without knowing whether the server will be able to
decrypt them.  Similarly, this can happen when a server sends 1-RTT
packets before confirming that the client has verified the server's
certificate and can therefore read these 1-RTT packets.
Paragraph (version A):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements in Initial
packets.
Paragraph (version A):
This exponential reduction in the sender's rate is important because
consecutive PTOs might be caused by loss of packets or
acknowledgements due to severe congestion.  Even when there are ack-
eliciting packets in-flight in multiple packet number spaces, the
exponential increase in probe timeout occurs across all spaces to
prevent excess load on the network.  For example, a timeout in the
Initial packet number space doubles the length of the timeout in the
Handshake packet number space.
Paragraph (version B):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgment is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgments in Initial
packets.
Paragraph (version B):
This exponential reduction in the sender's rate is important because
consecutive PTOs might be caused by loss of packets or
acknowledgments due to severe congestion.  Even when there are ack-
eliciting packets in-flight in multiple packet number spaces, the
exponential increase in probe timeout occurs across all spaces to
prevent excess load on the network.  For example, a timeout in the
Initial packet number space doubles the length of the timeout in the
Handshake packet number space.
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
acknowledgement 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 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 A):
Endpoints can also use coalesced packets (see Section 12.2 of QUIC-
TRANSPORT) to ensure that each datagram elicits at least one
acknowledgement.  For example, a client can coalesce an Initial
packet containing PING and PADDING frames with a 0-RTT data packet
and a server can coalesce an Initial packet containing a PING frame
with one or more packets in its first flight.
Paragraph (version B):
Endpoints can also use coalesced packets (see Section 12.2 of QUIC-
TRANSPORT) to ensure that each datagram elicits at least one
acknowledgment.  For example, a client can coalesce an Initial packet
containing PING and PADDING frames with a 0-RTT data packet and a
server can coalesce an Initial packet containing a PING frame with
one or more packets in its first flight.
Paragraph (version A):
If the sender wants to elicit a faster acknowledgement on PTO, it can
skip a packet number to eliminate the acknowledgment delay.
Paragraph (version B):
If the sender wants to elicit a faster acknowledgment on PTO, it can
skip a packet number to eliminate the acknowledgment delay.
Paragraph (version B):
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 A):
Probe packets MUST NOT be blocked by the congestion controller.  A
sender MUST however count these packets as being additionally in
flight, since these packets add network load without establishing
packet loss.  Note that sending probe packets might cause the
sender's bytes in flight to exceed the congestion window until an
acknowledgement is received that establishes loss or delivery of
packets.
Paragraph (version B):
Probe packets MUST NOT be blocked by the congestion controller.  A
sender MUST however count these packets as being additionally in
flight, since these packets add network load without establishing
packet loss.  Note that sending probe packets might cause the
sender's bytes in flight to exceed the congestion window until an
acknowledgment is received that establishes loss or delivery of
packets.
Paragraph (version B):
Packets 2 through 8 are declared lost when the acknowledgment for
packet 9 is received at t = 12.2.
Paragraph (version B):
Packets that carry only ACK frames can be heuristically identified by
observing packet size.  Acknowledgment 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.