Script updating gh-pages from 6910bce. [ci skip]

ianswett-generating-acknowledgements/draft-ietf-quic-transport.html

@@ -2179,22 +2179,22 @@ <h3 id="rfc.section.13.2.2">
 </h3>
 <p id="rfc.section.13.2.2.p.1">When an ACK frame is sent, one or more ranges of acknowledged packets are included.  Including older packets reduces the chance of spurious retransmits caused by losing previously sent ACK frames, at the cost of larger ACK frames.</p>
 <p id="rfc.section.13.2.2.p.2">ACK frames SHOULD always acknowledge the most recently received packets, and the more out-of-order the packets are, the more important it is to send an updated ACK frame quickly, to prevent the peer from declaring a packet as lost and spuriously retransmitting the frames it contains.</p>
-<p id="rfc.section.13.2.2.p.3">Below is one recommended approach for determining what packets to include in an ACK frame.</p>
+<p><a href="#ack-tracking" class="xref">Section 13.2.3</a> and <a href="#ack-limiting" class="xref">Section 13.2.4</a> describe an exemplary approach for determining what packets to acknowledge in each ACK frame.</p>
 <h3 id="rfc.section.13.2.3">
-<a href="#rfc.section.13.2.3">13.2.3.</a> <a href="#receiver-tracking-of-ack-frames" id="receiver-tracking-of-ack-frames">Receiver Tracking of ACK Frames</a>
+<a href="#rfc.section.13.2.3">13.2.3.</a> <a href="#ack-tracking" id="ack-tracking">Receiver Tracking of ACK Frames</a>
 </h3>
 <p id="rfc.section.13.2.3.p.1">When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the largest acknowledged in the sent ACK frame.</p>
 <p id="rfc.section.13.2.3.p.2">In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering. In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost. In this case, the loss recovery algorithm could cause spurious retransmits, but the sender will continue making forward progress.</p>
 <h3 id="rfc.section.13.2.4">
-<a href="#rfc.section.13.2.4">13.2.4.</a> <a href="#limiting-ack-ranges" id="limiting-ack-ranges">Limiting ACK Ranges</a>
+<a href="#rfc.section.13.2.4">13.2.4.</a> <a href="#ack-limiting" id="ack-limiting">Limiting ACK Ranges</a>
 </h3>
 <p id="rfc.section.13.2.4.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 or other small ACK-eliciting frame with a fraction of them, such as once per round trip, to enable dropping unnecessary ACK ranges and any state for previously sent packets.  The receiver MUST NOT bundle an ACK-eliciting frame, such as a PING, with all packets that would otherwise be non-ACK-eliciting, in order to avoid an infinite feedback loop of acknowledgements.</p>
 <p id="rfc.section.13.2.4.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 algorithms (<a href="#QUIC-RECOVERY" class="xref">[QUIC-RECOVERY]</a>) 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.2.5">
 <a href="#rfc.section.13.2.5">13.2.5.</a> <a href="#host-delay" id="host-delay">Measuring and Reporting Host Delay</a>
 </h3>
 <p id="rfc.section.13.2.5.p.1">An endpoint measures the delays intentionally introduced between when an ACK-eliciting packet is received and the corresponding acknowledgment is sent.  The endpoint encodes this delay for the largest acknowledged packet in the Ack Delay field of an ACK frame (see <a href="#frame-ack" class="xref">Section 19.3</a>). This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed. A packet might be held in the OS kernel or elsewhere on the host before being processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame.</p>
-<p id="rfc.section.13.2.5.p.2">An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.  max_ack_delay implies an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value. If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.</p>
+<p id="rfc.section.13.2.5.p.2">An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see <a href="#transport-parameter-definitions" class="xref">Section 18.2</a>.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value. If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.</p>
 <h3 id="rfc.section.13.2.6">
 <a href="#rfc.section.13.2.6">13.2.6.</a> <a href="#ack-frames-and-packet-protection" id="ack-frames-and-packet-protection">ACK Frames and Packet Protection</a>
 </h3>

ianswett-generating-acknowledgements/draft-ietf-quic-transport.txt

@@ -4047,8 +4047,8 @@ Internet-Draft           QUIC Transport Protocol          September 2019
    peer from declaring a packet as lost and spuriously retransmitting
    the frames it contains.
 
-   Below is one recommended approach for determining what packets to
-   include in an ACK frame.
+   Section 13.2.3 and Section 13.2.4 describe an exemplary approach for
+   determining what packets to acknowledge in each ACK frame.
 
 13.2.3.  Receiver Tracking of ACK Frames
 
@@ -4115,7 +4115,7 @@ Internet-Draft           QUIC Transport Protocol          September 2019
    An endpoint MUST NOT excessively delay acknowledgements of ack-
    eliciting packets.  An endpoint commits to a maximum delay using the
    max_ack_delay transport parameter; see Section 18.2.  max_ack_delay
-   implies an explicit contract: an endpoint promises to never delay
+   declares an explicit contract: an endpoint promises to never delay
    acknowledgments of an ack-eliciting packet by more than the indicated
    value.  If it does, any excess accrues to the RTT estimate and could
    result in delayed retransmissions from the peer.  For Initial and