Script updating gh-pages from 1c59334. [ci skip]

ianswett-appendix-recommended/draft-ietf-quic-recovery.html

@@ -2047,9 +2047,12 @@ <h3 id="name-persistent-congestion">
 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. The RECOMMENDED value
-for kPersistentCongestionThreshold is 3, which is approximately equivalent to
-having two TLPs before an RTO in TCP.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
+where PTOs do not occur or are substantially delayed. The rationale for this
+threshold is to enable a sender to use initial PTOs for aggressive probing,
+as TCP does with Tail Loss Probe (TLP) <span>[<a href="#RACK" class="xref">RACK</a>]</span>, before establishing persistent
+congestion, as TCP does with a Retransmission Timeout (RTO) <span>[<a href="#RFC5681" class="xref">RFC5681</a>]</span>.
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
 <p id="section-6.8-2">This duration is computed as follows:<a href="#section-6.8-2" class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-6.8-3">
 <pre>
@@ -2795,8 +2798,9 @@ <h2 id="name-constants-of-interest-2">
 </dd>
 <dt id="section-b.1-2.7">kPersistentCongestionThreshold:</dt>
 <dd id="section-b.1-2.8">
-  Period of time for persistent congestion to be established, as described in
-<a href="#persistent-congestion" class="xref">Section 6.8</a>, specified as a PTO multiplier.<a href="#section-b.1-2.8" class="pilcrow">¶</a>
+  Period of time for persistent congestion to be established, specified
+as a PTO multiplier. The <a href="#persistent-congestion" class="xref">Section 6.8</a> section recommends a
+value of 3.<a href="#section-b.1-2.8" class="pilcrow">¶</a>
 </dd>
 </dl>
 </section>

ianswett-appendix-recommended/draft-ietf-quic-recovery.txt

@@ -1051,13 +1051,13 @@ Internet-Draft             QUIC Loss Detection                March 2020
    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.  The RECOMMENDED value for
+   are substantially delayed.  The rationale for this threshold is to
+   enable a sender to use initial PTOs for aggressive probing, as TCP
+   does with Tail Loss Probe (TLP) [RACK], before establishing
+   persistent congestion, as TCP does with a Retransmission Timeout
+   (RTO) [RFC5681].  The RECOMMENDED value for
    kPersistentCongestionThreshold is 3, which is approximately
-   equivalent to having two TLPs before an RTO in TCP.
-
-   This duration is computed as follows:
-
-
+   equivalent to two TLPs before an RTO in TCP.
 
 
 
@@ -1066,6 +1066,8 @@ Iyengar & Swett         Expires 23 September 2020              [Page 19]
 Internet-Draft             QUIC Loss Detection                March 2020
 
 
+   This duration is computed as follows:
+
    (smoothed_rtt + 4 * rttvar + max_ack_delay) *
        kPersistentCongestionThreshold
 
@@ -1115,8 +1117,6 @@ Internet-Draft             QUIC Loss Detection                March 2020
 
 
 
-
-
 Iyengar & Swett         Expires 23 September 2020              [Page 20]
 
 Internet-Draft             QUIC Loss Detection                March 2020
@@ -1858,8 +1858,8 @@ Internet-Draft             QUIC Loss Detection                March 2020
       0.5.
 
    kPersistentCongestionThreshold:  Period of time for persistent
-      congestion to be established, as described in Section 6.8,
-      specified as a PTO multiplier.
+      congestion to be established, specified as a PTO multiplier.  The
+      Section 6.8 section recommends a value of 3.
 
 B.2.  Variables of interest