Script updating gh-pages from 4f2130e. [ci skip]

ianswett-ack-ack/draft-ietf-quic-transport.html

@@ -2069,7 +2069,7 @@ <h2 id="rfc.section.13.1">
 <h3 id="rfc.section.13.1.1">
 <a href="#rfc.section.13.1.1">13.1.1.</a> <a href="#sending-ack-frames" id="sending-ack-frames">Sending ACK Frames</a>
 </h3>
-<p id="rfc.section.13.1.1.p.1">Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently the can be sent.  An endpoint MUST NOT send more than one packet containing only an ACK frame per received ACK-eliciting packet(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ACK-eliciting packet(one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet. This prevents an indefinite feedback loop of acknowledgements, which may prevent the connection from ever becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to other packets.</p>
+<p id="rfc.section.13.1.1.p.1">Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent.  An endpoint MUST NOT send more than one packet containing only an ACK frame per received ACK-eliciting packet(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ACK-eliciting packet(one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet. This prevents an indefinite feedback loop of acknowledgements, which may prevent the connection from ever becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to other packets.</p>
 <p id="rfc.section.13.1.1.p.2">Packets containing PADDING frames are considered to be in flight for congestion control purposes <a href="#QUIC-RECOVERY" class="xref">[QUIC-RECOVERY]</a>. Sending only PADDING frames might cause the sender to become limited by the congestion controller (as described in <a href="#QUIC-RECOVERY" class="xref">[QUIC-RECOVERY]</a>) with no acknowledgments forthcoming from the receiver. Therefore, a sender SHOULD ensure that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver.</p>
 <p id="rfc.section.13.1.1.p.3">The receiver&#8217;s delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the <samp>max_ack_delay</samp> transport parameter.  This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received.  The sender can use the receiver&#8217;s <samp>max_ack_delay</samp> value in determining timeouts for timer-based retransmission.</p>
 <p id="rfc.section.13.1.1.p.4">Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in <a href="#QUIC-RECOVERY" class="xref">[QUIC-RECOVERY]</a>.</p>

ianswett-ack-ack/draft-ietf-quic-transport.txt

@@ -3825,8 +3825,8 @@ Internet-Draft           QUIC Transport Protocol               June 2019
 13.1.1.  Sending ACK Frames
 
    Packets containing only ACK frames are not congestion controlled, so
-   there are limits on how frequently the can be sent.  An endpoint MUST
-   NOT send more than one packet containing only an ACK frame per
+   there are limits on how frequently they can be sent.  An endpoint
+   MUST NOT send more than one packet containing only an ACK frame per
    received ACK-eliciting packet(one containing frames other than ACK
    and/or PADDING).  An endpoint MUST NOT send a packet containing only
    an ACK frame in response to a non-ACK-eliciting packet(one containing