Rewrite section on ack range limiting

draft-ietf-quic-transport.md

@@ -3260,27 +3260,32 @@ 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.
 
+
 ### Limiting ACK Ranges {#ack-limiting}
 
-To limit ACK Ranges (see {{ack-ranges}}) 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.
-
-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
-({{QUIC-RECOVERY}}) 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.
+A receiver MAY limit the number of ACK Ranges it sends to limit receiver state
+and the size of ACK frames.  A receiver SHOULD track which ACK frames have been
+acknowledged by its peer, so that it can limit ACK Ranges ({{ack-ranges}}) to
+those not yet acknowledged by the sender.
+
+It is possible that the ACK frame is too large, despite limiting ACK Ranges to
+those not yet acknowledged. A receiver can stop repeating unacknowledged ACK
+Ranges to further limit the size of the ACK frame.  When doing so, a receiver
+SHOULD give preference to acknowledging newly received packets to those received
+earlier.  It is possible that such ACK Ranges are not received by the sender
+causing the sender to unnecessarily retransmit those packets.
+
+A receiver that sends only non-ack-eliciting packets, such as ACK frames, might
+not receive an acknowledgement for a long period of time.  This could cause the
+receiver to maintain state for a large number of ACK frames for a long period of
+time, and ACK frames it sends could be unnecessarily large.  In such a case, a
+receiver could bundle a PING or other small ack-eliciting frame occasionally,
+such as once per round trip, to receive an ACK from the peer.
+
+A receiver MUST NOT bundle an ack-eliciting frame with all packets that would
+otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
+acknowledgements.
+
 
 ### Measuring and Reporting Host Delay {#host-delay}