Draft: draft-ietf-quic-recovery

Commentary: Also explains what happens to MinRTT if the path RTT changes . 
 Section 5.2 of draft - ietf - quic - recovery : ( 1 ) the minimum value observed over the lifetime of the connection Why a minimum specified over the entire lifetime ? There are paths where the initial RTT may the lower , I am unable to see why that artefact should have a long - term impact on the connection . Even if it is just a change in traffic sharing the path ’s bottleneck , it still is n’t something that needs to have impact for the lifetime of a connection . Ca n’t we decay the value somehow , so that it reflect the recent minRTT . draft - ietf - quic - recovery , and here is why a smaller than current minRTT is problematic : ( 2 ) MUST NOT apply the adjustment if the resulting RTT sample is smaller than the minrtt . This limits the underestimation that a misreporting peer can cause to the smoothedrtt . How do I understand this works with paths exhibiting varying path delay ? I still ca n’t fathom what will happen when the lowest RTT in recent time is much larger than the min_RTT , because the RTT floor has increased ( e.g. because of a change at L2 ) . I see some rather strange behaviour in traces of QUIC when there is large long - term jitter . At present , I think this results in making inappropriate adjustments ? 
 minrtt is used to reject implausible SRTT samples due to large maxackdelays , which we can clarify . It should be over the lifetime of the path , not the connection . We could clarify what it means to reset a context , but assuming a new context is easier to reason about . What if minrtt decreases or increases ? Decreases it should follow , Increases causes QUIC to loosen the sanity check . 
 ( Editorially I would specify a congestion control context rather than a path )
Paragraph (version A):
QUIC implements the spirit of existing TCP loss recovery mechanisms,
described in RFCs, various Internet-drafts, and also those prevalent
in the Linux TCP implementation.  This document describes QUIC
congestion control and loss recovery, and where applicable,
attributes the TCP equivalent in RFCs, Internet-drafts, academic
papers, and/or TCP implementations.
Paragraph (version A):
Packets containing CRYPTO data sent in Initial or Handshake
packets.
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 A):
QUIC endpoints measure the delay incurred between when a packet is
received and when the corresponding acknowledgment is sent, allowing
a peer to maintain a more accurate round-trip time estimate (see
host-delay).
Paragraph (version A):
An acknowledgement SHOULD be sent immediately upon receipt of a
second ack-eliciting packet.  QUIC recovery algorithms do not assume
the peer sends an ACK immediately when receiving a second ack-
eliciting packet.
Paragraph (version A):
In order to accelerate loss recovery and reduce timeouts, the
receiver SHOULD send an immediate ACK after it receives an out-of-
order packet.  It could send immediate ACKs for in-order packets for
a period of time that SHOULD NOT exceed 1/8 RTT unless more out-of-
order packets arrive.  If every packet arrives out-of- order, then an
immediate ACK SHOULD be sent for every received packet.
Paragraph (version A):
In order to quickly complete the handshake and avoid spurious
retransmissions due to crypto retransmission timeouts, crypto packets
SHOULD use a very short ack delay, such as the local timer
granularity.  ACK frames SHOULD be sent immediately when the crypto
stack indicates all data for that packet number space has been
received.
Paragraph (version A):
Below is one recommended approach for determining what packets to
include in an ACK frame.
Paragraph (version A):
In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering.  In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost.  In this case, the loss recovery
algorithm may cause spurious retransmits, but the sender will
continue making forward progress.
Paragraph (version A):
An endpoint measures the delays intentionally introduced between when
an ACK-eliciting packet is received and the corresponding
acknowledgment is sent.  The endpoint encodes this delay for the
largest acknowledged packet in the Ack Delay field of an ACK frame
(see Section 19.3 of QUIC-TRANSPORT).  This allows the receiver of
the ACK to adjust for any intentional delays, which is important for
delayed acknowledgements, when estimating the path RTT.  A packet
might be held in the OS kernel or elsewhere on the host before being
processed.  An endpoint SHOULD NOT include these unintentional delays
when populating the Ack Delay field in an ACK frame.
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 (host-
delay) 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):
QUIC endpoints measure the delay incurred between when a packet is
received and when the corresponding acknowledgment is sent, allowing
a peer to maintain a more accurate round-trip time estimate (see
Section 13.2 of QUIC-TRANSPORT).
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 A):
To avoid generating multiple RTT samples using the same packet, an
ACK frame SHOULD NOT be used to update RTT estimates if it does not
newly acknowledge the largest acknowledged packet.
Paragraph (version B):
To avoid generating multiple RTT samples for a single packet, an ACK
frame SHOULD NOT be used to update RTT estimates if it does not newly
acknowledge the largest acknowledged packet.
Paragraph (version A):
min_rtt is the minimum RTT observed over the lifetime of the
connection.  min_rtt is set to the latest_rtt on the first sample in
a connection, and to the lesser of min_rtt and latest_rtt on
subsequent samples.
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 (host-
delay).  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):
smoothed_rtt is an exponentially-weighted moving average of an
endpoint's RTT samples, and rttvar is the endpoint's estimated
variance in the RTT samples.
Paragraph (version A):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for host delays (host-delay).  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 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 A):
MUST use the lesser of the value reported in Ack Delay field of
the ACK frame and the peer's max_ack_delay transport parameter
(host-delay).
Paragraph (version A):
On the first RTT sample in a connection, the smoothed_rtt is set to
the latest_rtt.
Paragraph (version A):
If a packet is lost, the QUIC transport needs to recover from that
loss, such as by retransmitting the data, sending an updated frame,
or abandoning the frame.  For more information, see Section 13.2 of
QUIC-TRANSPORT.
Paragraph (version B):
MUST use the lesser of the value reported in Ack Delay field of
the ACK frame and the peer's max_ack_delay transport parameter.
Paragraph (version B):
On the first RTT sample for a network path, the smoothed_rtt is set
to the latest_rtt.
Paragraph (version B):
QUIC senders use acknowledgements to detect lost packets, and a probe
time out pto to ensure acknowledgements are received.  This section
provides a description of these algorithms.
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 A):
The RECOMMENDED initial value for the packet reordering threshold
(kPacketThreshold) is 3, based on best practices for TCP loss
detection RFC5681 RFC6675.
Paragraph (version A):
A Probe Timeout (PTO) triggers sending one or two probe packets when
ack-eliciting packets are not acknowledged within the expected period
of time or the handshake has not been completed.  A PTO enables a
connection to recover from loss of tail packets or acks.  The PTO
algorithm used in QUIC implements the reliability functions of Tail
Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP
RFC5682, and the timeout computation is based on TCP's retransmission
timeout period RFC6298.
Paragraph (version B):
Implementations MAY experiment with absolute thresholds, thresholds
from previous connections, adaptive thresholds, or including RTT
variation.  Smaller thresholds reduce reordering resilience and
increase spurious retransmissions, and larger thresholds increase
loss detection delay.
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 variance in the
estimate (4*rttvar), and max_ack_delay, to account for the maximum
time by which a receiver might delay sending an acknowledgement.
Paragraph (version A):
When a PTO timer expires, the PTO period MUST be set to twice its
current value.  This exponential reduction in the sender's rate is
important because the PTOs might be caused by loss of packets or
acknowledgements due to severe congestion.  The life of a connection
that is experiencing consecutive PTOs is limited by the endpoint's
idle timeout.
Paragraph (version A):
A sender computes its PTO timer every time an ack-eliciting packet is
sent.  A sender might choose to optimize this by setting the timer
fewer times if it knows that more ack-eliciting packets will be sent
within a short period of time.
Paragraph (version B):
The life of a connection that is experiencing consecutive PTOs is
limited by the endpoint's idle timeout.
Paragraph (version A):
Because the server could be blocked until more packets are received,
the client MUST ensure that the retransmission timer is set if the
client does not yet have 1-RTT keys.  If the probe timer expires
before the client has 1-RTT keys, it is possible that the client may
not have any crypto data to retransmit.  However, the client MUST
send a new packet, containing only PADDING frames if necessary, to
allow the server to continue sending data.  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):
Because Initial packets containing only PADDING do not elicit an
acknowledgement, they may never be acknowledged, but they are removed
from bytes in flight when the client gets Handshake keys and the
Initial keys are discarded.
Paragraph (version B):
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.
Paragraph (version B):
Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to
an incorrect RTT estimate at the client.  To allow the client to
improve its RTT estimate, the new packet that it sends MUST be ack-
eliciting.  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):
Probe packets sent on a PTO MUST be ack-eliciting.  A probe packet
SHOULD carry new data when possible.  A probe packet MAY carry
retransmitted unacknowledged data when new data is unavailable, when
flow control does not permit new data to be sent, or to
opportunistically reduce loss recovery delay.  Implementations MAY
use alternate strategies for determining the content of probe
packets, including sending new or retransmitted data based on the
application's priorities.
Paragraph (version A):
If a path has been verified to support ECN, QUIC treats a Congestion
Experienced codepoint in the IP header as a signal of congestion.
This document specifies an endpoint's response when its peer receives
packets with the Congestion Experienced codepoint.  As discussed in
RFC8311, endpoints are permitted to experiment with other response
functions.
Paragraph (version A):
Bursting more than an intial window's worth of data into the network
might cause short-term congestion and losses.  Implemementations
SHOULD either use pacing or reduce their congestion window to limit
such bursts.
Paragraph (version B):
A sender MAY implement alternative mechanisms to update its
congestion window after periods of under-utilization, such as those
proposed for TCP in RFC7661.
Paragraph (version A):
A sender MAY attempt to detect suppression of reports by marking
occasional packets that they send with ECN-CE.  If a packet marked
with ECN-CE is not reported as having been marked when the packet is
acknowledged, the sender SHOULD then disable ECN for that path.