Script updating gh-pages from 8bd39d9. [ci skip]

draft-ietf-quic-recovery.html

@@ -922,15 +922,15 @@ <h2 id="rfc.section.6.8">
 </h2>
 <p id="rfc.section.6.8.p.1">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 smoothed RTT when used with a window-based controller, and a pacer might use the rate estimate of a rate-based controller.</p>
 <p id="rfc.section.6.8.p.2">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.</p>
-<p id="rfc.section.6.8.p.3">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).</p>
+<p id="rfc.section.6.8.p.3">Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such bursts to minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window.</p>
+<p id="rfc.section.6.8.p.4">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).</p>
 <h2 id="rfc.section.6.9">
 <a href="#rfc.section.6.9">6.9.</a> <a href="#under-utilizing-the-congestion-window" id="under-utilizing-the-congestion-window">Under-utilizing the Congestion Window</a>
 </h2>
 <p id="rfc.section.6.9.p.1">When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-utilized.  When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance. This can happen due to insufficient application data or flow control credit.</p>
 <p id="rfc.section.6.9.p.2">A sender MAY use the pipeACK method described in section 4.3 of <a href="#RFC7661" class="xref">[RFC7661]</a> to determine if the congestion window is sufficiently utilized.</p>
 <p id="rfc.section.6.9.p.3">A sender that paces packets (see <a href="#pacing" class="xref">Section 6.8</a>) 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.</p>
-<p id="rfc.section.6.9.p.4">Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations SHOULD either use pacing or reduce their congestion window to limit such bursts to minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window.</p>
-<p id="rfc.section.6.9.p.5">A sender MAY implement alternative mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in <a href="#RFC7661" class="xref">[RFC7661]</a>.</p>
+<p id="rfc.section.6.9.p.4">A sender MAY implement alternative mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in <a href="#RFC7661" class="xref">[RFC7661]</a>.</p>
 <h1 id="rfc.section.7">
 <a href="#rfc.section.7">7.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
 </h1>

draft-ietf-quic-recovery.txt

@@ -986,6 +986,13 @@ Internet-Draft             QUIC Loss Detection              October 2019
    frames should therefore not be paced, to avoid delaying their
    delivery to the peer.
 
+   Sending multiple packets into the network without any delay between
+   them creates a packet burst that might cause short-term congestion
+   and losses.  Implementations MUST either use pacing or limit such
+   bursts to minimum of 10 * kMaxDatagramSize and max(2*
+   kMaxDatagramSize, 14720)), the same as the recommended initial
+   congestion window.
+
    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).
@@ -995,13 +1002,6 @@ Internet-Draft             QUIC Loss Detection              October 2019
    When bytes in flight is smaller than the congestion window and
    sending is not pacing limited, the congestion window is under-
    utilized.  When this occurs, the congestion window SHOULD NOT be
-   increased in either slow start or congestion avoidance.  This can
-   happen due to insufficient application data or flow control credit.
-
-   A sender MAY use the pipeACK method described in section 4.3 of
-   [RFC7661] to determine if the congestion window is sufficiently
-   utilized.
-
 
 
 
@@ -1010,18 +1010,18 @@ Iyengar & Swett          Expires April 19, 2020                [Page 18]
 Internet-Draft             QUIC Loss Detection              October 2019
 
 
+   increased in either slow start or congestion avoidance.  This can
+   happen due to insufficient application data or flow control credit.
+
+   A sender MAY use the pipeACK method described in section 4.3 of
+   [RFC7661] to determine if the congestion window is sufficiently
+   utilized.
+
    A sender that paces packets (see Section 6.8) 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.
 
-   Sending multiple packets into the network without any delay between
-   them creates a packet burst that might cause short-term congestion
-   and losses.  Implementations SHOULD either use pacing or reduce their
-   congestion window to limit such bursts to minimum of 10 *
-   kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as
-   the recommended initial congestion window.
-
    A sender MAY implement alternative mechanisms to update its
    congestion window after periods of under-utilization, such as those
    proposed for TCP in [RFC7661].