Draft: draft-ietf-quic-recovery

Commentary: This attempts to fix  's editorial comments from the QUIC mailing list .
Paragraph (version A):
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 QUIC-TRANSPORT.
Packet numbers never repeat within a packet number space for the
lifetime of a connection.  Packet numbers monotonically increase
within a space, preventing ambiguity.
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 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.
Paragraph (version A):
QUIC starts a loss epoch when a packet is lost and ends one when any
packet sent after the epoch starts is acknowledged.  TCP waits for
the gap in the sequence number space to be filled, and so if a
segment is lost multiple times in a row, the loss epoch may not end
for several round trips.  Because both should reduce their congestion
windows only once per epoch, QUIC will do it correctly once for every
round trip that experiences loss, while TCP may only do it once
across multiple round trips.
Paragraph (version B):
QUIC starts a loss epoch when a packet is lost and ends one when any
packet sent after the epoch starts is acknowledged.  TCP waits for
the gap in the sequence number space to be filled, and so if a
segment is lost multiple times in a row, the loss epoch may not end
for several round trips.  Because both should reduce their congestion
windows only once per epoch, QUIC will do it once for every round
trip that experiences loss, while TCP may only do it once across
multiple round trips.
Paragraph (version A):
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 connection's RTT.  An endpoint computes the following three
values: the minimum value observed over the lifetime of the
connection (min_rtt), an exponentially-weighted moving average
(smoothed_rtt), and the variance in the observed RTT samples
(rttvar).
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 ACK delays (see
Section 13.2 of QUIC-TRANSPORT) to generate a statistical description
of the connection's RTT.  An endpoint computes the following three
values: the minimum value observed over the lifetime of the
connection (min_rtt), an exponentially-weighted moving average
(smoothed_rtt), and the variance in the observed RTT samples
(rttvar).
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 host
delays for only the largest acknowledged packet in an ACK frame.
While the reported host 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):
An endpoint uses only locally observed times in computing the min_rtt
and does not adjust for host delays reported by the peer.  Doing so
allows the endpoint to set a lower bound for the smoothed_rtt based
entirely on what it observes (see smoothed-rtt), and limits potential
underestimation due to erroneously-reported delays by the peer.
Paragraph (version B):
An endpoint uses only locally observed times in computing the min_rtt
and does not adjust for ACK delays reported by the peer.  Doing so
allows the endpoint to set a lower bound for the smoothed_rtt based
entirely on what it observes (see smoothed-rtt), and limits potential
underestimation due to erroneously-reported delays by the peer.
Paragraph (version A):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for host delays.  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 ACK delays.  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 A):
The acknowledgement indicates that a packet sent later was delivered,
while the packet and time thresholds provide some tolerance for
packet reordering.
Paragraph (version B):
The acknowledgement indicates that a packet sent later was delivered,
and the packet and time thresholds provide some tolerance for packet
reordering.
Paragraph (version A):
A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to seed initial_rtt for a new path, but the
delay SHOULD NOT be considered an RTT sample.
Paragraph (version B):
A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to seed the initial RTT for a new path, but
the delay SHOULD NOT be considered an RTT sample.
Paragraph (version A):
QUIC begins every connection in slow start and exits slow start upon
loss or upon increase in the ECN-CE counter.  QUIC re-enters slow
start anytime the congestion window is less than ssthresh, which only
occurs after persistent congestion is declared.  While in slow start,
QUIC increases the congestion window by the number of bytes
acknowledged when each acknowledgment is processed.
Paragraph (version B):
QUIC begins every connection in slow start and exits slow start upon
loss or upon increase in the ECN-CE counter.  QUIC re-enters slow
start any time the congestion window is less than ssthresh, which
only occurs after persistent congestion is declared.  While in slow
start, QUIC increases the congestion window by the number of bytes
acknowledged when each acknowledgment is processed.
Paragraph (version A):
The first three packets are determined to be lost when the ACK of
packet 4 is received at t=8.  The congestion period is calculated as
the time between the oldest and newest lost packets: (3 - 0) = 3.
The duration for persistent congestion is equal to: (1 *
kPersistentCongestionThreshold) = 3.  Because the threshold was
reached and because none of the packets between the oldest and the
newest packets are acknowledged, the network is considered to have
experienced persistent congestion.
Paragraph (version B):
The first three packets are determined to be lost when the
acknowlegement of packet 4 is received at t=8.  The congestion period
is calculated as the time between the oldest and newest lost packets:
(3 - 0) = 3.  The duration for persistent congestion is equal to: (1
* kPersistentCongestionThreshold) = 3.  Because the threshold was
reached and because none of the packets between the oldest and the
newest packets are acknowledged, the network is considered to have
experienced persistent congestion.