Promote section 3.1 to its own section

draft-ietf-quic-recovery.md

@@ -151,14 +151,14 @@ of frames contained in a packet affect recovery and congestion control logic:
 * PADDING frames cause packets to contribute toward bytes in flight without
   directly causing an acknowledgment to be sent.
 
-## Relevant Differences Between QUIC and TCP
+# Relevant Differences Between QUIC and TCP
 
 Readers familiar with TCP's loss detection and congestion control will find
 algorithms here that parallel well-known TCP ones. Protocol differences between
 QUIC and TCP however contribute to algorithmic differences. We briefly describe
 these protocol differences below.
 
-### Separate Packet Number Spaces
+## Separate Packet Number Spaces
 
 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
@@ -167,7 +167,7 @@ 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.
 
-### Monotonically Increasing Packet Numbers
+## Monotonically Increasing Packet Numbers
 
 TCP conflates transmission order at the sender with delivery order at the
 receiver, which results in retransmissions of the same data carrying the same
@@ -192,7 +192,7 @@ Most TCP mechanisms implicitly attempt to infer transmission ordering based on
 TCP sequence numbers - a non-trivial task, especially when TCP timestamps are
 not available.
 
-### Clearer Loss Epoch
+## Clearer Loss Epoch
 
 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
@@ -202,25 +202,25 @@ 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.
 
-### No Reneging
+## No Reneging
 
 QUIC ACKs contain information that is similar to TCP SACK, but QUIC does not
 allow any acked packet to be reneged, greatly simplifying implementations on
 both sides and reducing memory pressure on the sender.
 
-### More ACK Ranges
+## More ACK Ranges
 
 QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In high loss
 environments, this speeds recovery, reduces spurious retransmits, and ensures
 forward progress without relying on timeouts.
 
-### Explicit Correction For Delayed Acknowledgements
+## Explicit Correction For Delayed Acknowledgements
 
 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}}.
 
-### Probe Timeout Replaces RTO and TLP
+## Probe Timeout Replaces RTO and TLP
 
 QUIC uses a probe timeout (see {{pto}}), with a timer based on TCP's RTO
 computation.  QUIC's PTO includes the peer's maximum expected acknowledgement
@@ -245,7 +245,7 @@ QUIC specifies a time-based definition to ensure one or more packets are sent
 prior to a dramatic decrease in congestion window; see
 {{persistent-congestion}}.
 
-### The Minimum Congestion Window is Two Packets
+## The Minimum Congestion Window is Two Packets
 
 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
@@ -572,10 +572,10 @@ estimate, the new packet that it sends MUST be ack-eliciting.
 
 Initial packets and Handshake packets could be never acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded,
-as described below in Section {{discarding-packets}}. When Initial or Handshake
-keys are discarded, the PTO and loss detection timers MUST be reset, because
-discarding keys indicates forward progress and the loss detection timer might
-have been set for a now discarded packet number space.
+as described below in {{discarding-packets}}. When Initial or Handshake keys are
+discarded, the PTO and loss detection timers MUST be reset, because discarding
+keys indicates forward progress and the loss detection timer might have been set
+for a now discarded packet number space.
 
 #### Before Address Validation
 

draft-ietf-quic-transport.md

@@ -1824,10 +1824,10 @@ could occur when the server reaches its anti-amplification limit and the client
 has received acknowledgements for all the data it has sent.  In this case, when
 the client has no reason to send additional packets, the server will be unable
 to send more data because it has not validated the client's address. To prevent
-this deadlock, clients MUST send a packet on a probe timeout
-(PTO, see Section 5.3 of {{QUIC-RECOVERY}}). Specifically, the client MUST send
-an Initial packet in a UDP datagram of at least 1200 bytes if it does not have
-Handshake keys, and otherwise send a Handshake packet.
+this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section
+6.2 of {{QUIC-RECOVERY}}). Specifically, the client MUST send an Initial packet
+in a UDP datagram of at least 1200 bytes if it does not have Handshake keys, and
+otherwise send a Handshake packet.
 
 A server might wish to validate the client address before starting the
 cryptographic handshake. QUIC uses a token in the Initial packet to provide
@@ -2390,11 +2390,11 @@ path is no longer needed (such as the case in {{off-path-forward}}).
 A sender can make exceptions for probe packets so that their loss detection is
 independent and does not unduly cause the congestion controller to reduce its
 sending rate.  An endpoint might set a separate timer when a PATH_CHALLENGE is
-sent, which is cancelled if the corresponding PATH_RESPONSE is received. If
-the timer fires before the PATH_RESPONSE is received, the endpoint might send a
-new PATH_CHALLENGE, and restart the timer for a longer period of time.
-This timer SHOULD be set as described in Section 5.3 of {{QUIC-RECOVERY}} and
-MUST NOT be more aggressive.
+sent, which is cancelled if the corresponding PATH_RESPONSE is received. If the
+timer fires before the PATH_RESPONSE is received, the endpoint might send a new
+PATH_CHALLENGE, and restart the timer for a longer period of time.  This timer
+SHOULD be set as described in Section 6.2.1 of {{QUIC-RECOVERY}} and MUST NOT be
+more aggressive.
 
 
 ## Privacy Implications of Connection Migration {#migration-linkability}
@@ -2667,7 +2667,7 @@ An endpoint that sends packets close to the effective timeout risks having
 them be discarded at the peer, since the peer might enter its draining state
 before these packets arrive. An endpoint can send a PING or another
 ack-eliciting frame to test the connection for liveness if the peer could
-time out soon, such as within a PTO; see Section 6.6 of {{QUIC-RECOVERY}}.
+time out soon, such as within a PTO; see Section 6.2 of {{QUIC-RECOVERY}}.
 This is especially useful if any available application data cannot be safely
 retried. Note that the application determines what data is safe to retry.
 
@@ -3397,7 +3397,7 @@ accrues to the RTT estimate and could result in spurious or delayed
 retransmissions from the peer. For Initial and Handshake packets, a
 max_ack_delay of 0 is used. The sender uses the receiver's max_ack_delay value
 in determining timeouts for timer-based retransmission, as detailed in Section
-5.2.1 of {{QUIC-RECOVERY}}.
+6.2 of {{QUIC-RECOVERY}}.
 
 Since packets containing only ACK frames are not congestion controlled, an
 endpoint MUST NOT send more than one such packet in response to receiving an
@@ -3440,9 +3440,9 @@ frames.
 A receiver determines how frequently to send acknowledgements in response to
 ack-eliciting packets. This determination involves a tradeoff.
 
-Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+Endpoints rely on timely acknowledgment to detect loss; see Section 6 of
 {{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
-Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their
+Section 7 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their
 congestion window. In both cases, delaying acknowledgments can adversely affect
 performance.
 
@@ -4377,7 +4377,7 @@ when it receives its first Handshake packet.  Though packets might still be in
 flight or awaiting acknowledgment, no further Initial packets need to be
 exchanged beyond this point.  Initial packet protection keys are discarded (see
 Section 4.11.1 of {{QUIC-TLS}}) along with any loss recovery and congestion
-control state; see Section 6.5 of {{QUIC-RECOVERY}}.
+control state; see Section 6.4 of {{QUIC-RECOVERY}}.
 
 Any data in CRYPTO frames is discarded - and no longer retransmitted - when
 Initial keys are discarded.