Persistent Congestion Time Threshold

draft-ietf-quic-recovery.md

@@ -645,14 +645,22 @@ 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.
 
+## Persistent Congestion
+
 When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and 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}}.
+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.  This duration is the
+equivalent of kPersistentCongestionThreshold consecutive PTOS: smoothed_rtt +
+4 * rttvar + max_ack_delay * ((2 ^ kPersistentCongestionThreshold) - 1).
+
+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}}.
 
 ## Pacing {#pacing}
 
@@ -1119,110 +1127,7 @@ DetectLostPackets():
 We now describe an example implementation of the congestion controller described
 in {{congestion-control}}.
 
-## Congestion Avoidance
-
-Slow start exits to congestion avoidance.  Congestion avoidance in NewReno
-uses an additive increase multiplicative decrease (AIMD) approach that
-increases the congestion window by one maximum packet size per
-congestion window acknowledged.  When a loss is detected, NewReno halves
-the congestion window and sets the slow start threshold to the new
-congestion window.
-
-## Recovery Period
-
-Recovery is a period of time beginning with detection of a lost packet or an
-increase in the ECN-CE counter. Because QUIC does not retransmit packets,
-it defines the end of recovery as a packet sent after the start of recovery
-being acknowledged. This is slightly different from TCP's definition of
-recovery, which ends when the lost packet that started recovery is acknowledged.
-
-The recovery period limits congestion window reduction to once per round trip.
-During recovery, the congestion window remains unchanged irrespective of new
-losses or increases in the ECN-CE counter.
-
-## Ignoring Loss of Undecryptable Packets
-
-During the handshake, some packet protection keys might not be
-available when a packet arrives. In particular, Handshake and 0-RTT packets
-cannot be processed until the Initial packets arrive, and 1-RTT packets
-cannot be processed until the handshake completes.  Endpoints MAY
-ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before
-the peer has packet protection keys to process those packets.
-
-## Probe Timeout
-
-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
-adds 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.
-
-## Persistent Congestion
-
-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.  This duration is the
-equivalent of kPersistentCongestionThreshold consecutive PTOS: smoothed_rtt +
-4 * rttvar + max_ack_delay * ((2 ^ kPersistentCongestionThreshold) - 1).
-
-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}}.
-
-## Pacing {#pacing}
-
-This document does not specify a pacer, but it is RECOMMENDED that a sender pace
-sending of all in-flight packets based on input from the congestion
-controller. For example, a pacer might distribute the congestion window over
-the SRTT when used with a window-based controller, and a pacer might use the
-rate estimate of a rate-based controller.
-
-An implementation should take care to architect its congestion controller to
-work well with a pacer.  For instance, a pacer might wrap the congestion
-controller and control the availability of the congestion window, or a pacer
-might pace out packets handed to it by the congestion controller. Timely
-delivery of ACK frames is important for efficient loss recovery. Packets
-containing only ACK frames should therefore not be paced, to avoid delaying
-their delivery to the peer.
-
-As an example of a well-known and publicly available implementation of a flow
-pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
-in Linux (3.11 onwards).
-
-
-## Sending data after an idle period
-
-A sender becomes idle if it ceases to send data and has no bytes in flight.  A
-sender's congestion window MUST NOT increase while it is idle.
-
-When sending data after becoming idle, a sender MUST reset its congestion window
-to the initial congestion window (see Section 4.1 of {{?RFC5681}}), unless it
-paces the sending of packets. A sender MAY retain its congestion window if it
-paces the sending of any packets in excess of the initial congestion window.
-
-A sender MAY implement alternate mechanisms to update its congestion window
-after idle periods, such as those proposed for TCP in {{?RFC7661}}.
-
-## Application Limited Sending
-
-The congestion window should not be increased in slow start or congestion
-avoidance when it is not fully utilized.  The congestion window could be
-under-utilized due to insufficient application data or flow control credit.
-
-A sender that paces packets (see {{pacing}}) might delay sending packets
-and not fully utilize the congestion window due to this delay. A sender
-should not consider itself application limited if it would have fully
-utilized the congestion window without pacing delay.
-
-## Pseudocode
-
-### Constants of interest {#cc-consts-of-interest}
+## Constants of interest {#cc-consts-of-interest}
 
 Constants used in congestion control are based on a combination of RFCs,
 papers, and common practice.  Some may need to be changed or negotiated