A Congestion Control state machine

This adds a state machine and makes further changes to the presentation
of the congestion control states in line with that presentation.  This
rolls in the normative changes from #3978.

Closes #4045.

draft-ietf-quic-recovery.md

@@ -762,62 +762,95 @@ The minimum congestion window is the smallest value the congestion window can
 decrease to as a response to loss, ECN-CE, or persistent congestion.
 The RECOMMENDED value is 2 * max_datagram_size.
 
-## Slow Start
+## Congestion Control States
 
-The congestion controller is in slow start any time the congestion window is
-below the slow start threshold.  The congestion controller begins in slow start
-because the slow start threshold is initialized to an infinite value.
+The congestion controller has three distinct states, as shown in
+{{fig-cc-fsm}}.
 
-While the congestion controller is in slow start, the congestion window
-increases by the number of bytes acknowledged when each acknowledgment is
-processed.  This results in exponential growth of the congestion window.
+~~~
+                 Start or         +------------+
+            persistent congestion |   Slow     |
+        (O)---------------------->|   Start    |
+                                  +------------+
+                                        |
+                                Loss or |
+                        ECN-CE increase |
+                                        v
+ +------------+     Loss or       +------------+
+ | Congestion |  ECN-CE increase  |  Recovery  |
+ | Avoidance  |------------------>|   Period   |
+ +------------+                   +------------+
+           ^                            |
+           |                            |
+           +----------------------------+
+              Acknowledgment of packet
+                sent during recovery
+~~~
+{: #fig-cc-fsm title="Congestion Control States and Transitions"}
 
-The congestion controller exits slow start and enters congestion avoidance when
-a packet is lost or when the ECN-CE count increases.
+These states and the transitions between them are described in subsequent
+sections.
 
-The congestion controller re-enters slow start any time the congestion window is
-less than the slow start threshold, which only occurs after persistent
-congestion is declared.
+### Slow Start
 
-## Congestion Avoidance
+A sender is in slow start any time the congestion window is below the slow
+start threshold. A sender begins in slow start because the slow start threshold
+is initialized to an infinite value.
 
-The congestion controller is in congestion avoidance any time the congestion
-window is at or above the slow start threshold.
+While a sender is in slow start, the congestion window increases by the number
+of bytes acknowledged when each acknowledgment is processed. This results in
+exponential growth of the congestion window.
 
-Congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD)
-approach that increases the congestion window by one maximum datagram size per
-congestion window acknowledged. A congestion controller MUST NOT increase the
-congestion window by more than this amount.
+The sender exits slow start and enters a recovery period when a packet is lost
+or when the ECN-CE count reported by its peer increases.
 
-The congestion controller described in this document, when not in the recovery
-period ({{recovery-period}}), MUST take the following steps when first entering
-congestion avoidance, when a packet is declared lost, or when the ECN-CE count
-is increased:
+A sender re-enters slow start any time the congestion window is less than the
+slow start threshold, which only occurs after persistent congestion is
+declared.
 
-* halve the congestion window,
-* set the slow start threshold to the size of the reduced congestion window, and
-* enter the recovery period.
+### Recovery Period {#recovery-period}
 
-## Recovery Period {#recovery-period}
+A sender enters the recovery period when it detects the loss of a packet or the
+ECN-CE count reported by its peer increases. A sender that is already in a
+recovery period stays in it and does not re-enter it.
 
-A recovery period is entered when loss or ECN-CE marking of a packet is
-detected in congestion avoidance after the congestion window and slow start
-threshold have been decreased.  A recovery period ends when a packet sent
-during the recovery period is acknowledged.  This is slightly different from
-TCP's definition of recovery, which ends when the lost packet that started
-recovery is acknowledged.
+On entering a recovery period, a sender MUST set the slow start threshold to
+the half the value of the congestion window at the moment that loss is
+detected. The congestion window MUST be set to the reduced value of the slow
+start threshold before exiting the recovery period. Implementations MAY set the
+congestion window immediately on entering a recovery period or use other
+mechanisms, such as Proportional Rate Reduction ({{?PRR=RFC6937}}), to reduce
+it more gradually.
 
 The recovery period aims to limit congestion window reduction to once per round
-trip. Therefore during recovery, the congestion window remains unchanged
-irrespective of new losses or increases in the ECN-CE counter.
+trip. Therefore during a recovery period, the congestion window remains does
+not change in response to new losses or increases in the ECN-CE count.
+
+A recovery period ends and the sender enters congestion avoidance when a packet
+sent during the recovery period is acknowledged. This is slightly different
+from TCP's definition of recovery, which ends when the lost packet that started
+recovery is acknowledged.
 
-When entering recovery, a single packet MAY be sent even if bytes in flight
-now exceeds the recently reduced congestion window.  This speeds up loss
+When entering a recovery period, a single packet MAY be sent even if bytes in
+flight now exceeds the recently reduced congestion window.  This speeds up loss
 recovery if the data in the lost packet is retransmitted and is similar to TCP
 as described in Section 5 of {{?RFC6675}}.  If further packets are lost while
 the sender is in recovery, sending any packets in response MUST obey the
 congestion window limit.
 
+### Congestion Avoidance
+
+A sender is in congestion avoidance any time the congestion window is at or
+above the slow start threshold and not in a recovery period.
+
+A NewReno sender in congestion avoidance uses an Additive Increase
+Multiplicative Decrease (AIMD) approach that MUST limit the increase to the
+congestion window to at most one maximum datagram size for each congestion
+window that is acknowledged.
+
+The sender exits congestion avoidance and enters a recovery period when a
+packet is lost or when the ECN-CE count reported by its peer increases.
+
 ## Ignoring Loss of Undecryptable Packets
 
 During the handshake, some packet protection keys might not be available when