Script updating gh-pages from e4296ef. [ci skip]

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

@@ -2075,14 +2075,14 @@ <h3 id="rfc.section.13.1.1">
 <p id="rfc.section.13.1.1.p.1">An endpoint sends ACK frames to acknowledge packets it has received and processed.</p>
 <p id="rfc.section.13.1.1.p.2">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 ACK-frame-only packet in response to receiving an 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. Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to ACK-eliciting packets.</p>
 <p id="rfc.section.13.1.1.p.3">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.4">An endpoint that is only sending acknowledgements will not receive acknowledgments from its peer unless those acknowledgements are included in packets with ACK-eliciting frames.  A sender SHOULD bundle ACK frames with other frames when there are new ACK-eliciting packets to acknowledge.  When only non-ACK-eliciting packets need to be acknowledged, the sender MAY wait until an ACK-eliciting packet has been received to bundle an ACK frame with outgoing frames.</p>
+<p id="rfc.section.13.1.1.p.4">An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgements are included in packets with ACK-eliciting frames.  A sender SHOULD bundle ACK frames with other frames when there are new ACK-eliciting packets to acknowledge.  When only non-ACK-eliciting packets need to be acknowledged, the sender MAY wait until an ACK-eliciting packet has been received to bundle an ACK frame with outgoing frames.</p>
 <p id="rfc.section.13.1.1.p.5">An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition.</p>
 <p id="rfc.section.13.1.1.p.6">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.7">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>
 <h3 id="rfc.section.13.1.2">
 <a href="#rfc.section.13.1.2">13.1.2.</a> <a href="#limiting-ack-ranges" id="limiting-ack-ranges">Limiting ACK ranges</a>
 </h3>
-<p id="rfc.section.13.1.2.p.1">To limit ACK Ranges (see <a href="#ack-ranges" class="xref">Section 19.3.1</a>) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size.  When the receiver is only sending non-ACK-eliciting packets, it can bundle a PING with a fraction of them, such as one per round trip, to enable dropping unnecessary ACK ranges and any state for previously sent packets.  The receiver MUST NOT bundle a PING with all packets that would otherwise not be ACK-eliciting, in order to avoid an indefinite feedback loop of acknowledgements.</p>
+<p id="rfc.section.13.1.2.p.1">To limit ACK Ranges (see <a href="#ack-ranges" class="xref">Section 19.3.1</a>) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size.  When the receiver is only sending non-ACK-eliciting packets, it can bundle a PING with a fraction of them, such as one per round trip, to enable dropping unnecessary ACK ranges and any state for previously sent packets.  The receiver MUST NOT bundle a PING with all packets that would otherwise not be ACK-eliciting, in order to avoid an infinite feedback loop of acknowledgements.</p>
 <p id="rfc.section.13.1.2.p.2">To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK Ranges it sends.  A receiver can do this even without receiving acknowledgment of its ACK frames, with the knowledge this could cause the sender to unnecessarily retransmit some data.  Standard QUIC <a href="#QUIC-RECOVERY" class="xref">[QUIC-RECOVERY]</a> algorithms declare packets lost after sufficiently newer packets are acknowledged.  Therefore, the receiver SHOULD repeatedly acknowledge newly received packets in preference to packets received in the past.</p>
 <h3 id="rfc.section.13.1.3">
 <a href="#rfc.section.13.1.3">13.1.3.</a> <a href="#ack-frames-and-packet-protection" id="ack-frames-and-packet-protection">ACK Frames and Packet Protection</a>

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

@@ -3848,7 +3848,7 @@ Internet-Draft           QUIC Transport Protocol               July 2019
    that other frames are sent in addition to PADDING frames to elicit
    acknowledgments from the receiver.
 
-   An endpoint that is only sending acknowledgements will not receive
+   An endpoint that is only sending ACK frames will not receive
    acknowledgments from its peer unless those acknowledgements are
    included in packets with ACK-eliciting frames.  A sender SHOULD
    bundle ACK frames with other frames when there are new ACK-eliciting
@@ -3892,7 +3892,7 @@ Internet-Draft           QUIC Transport Protocol               July 2019
    enable dropping unnecessary ACK ranges and any state for previously
    sent packets.  The receiver MUST NOT bundle a PING with all packets
    that would otherwise not be ACK-eliciting, in order to avoid an
-   indefinite feedback loop of acknowledgements.
+   infinite feedback loop of acknowledgements.
 
    To limit receiver state or the size of ACK frames, a receiver MAY
    limit the number of ACK Ranges it sends.  A receiver can do this even