Re: [quicwg/base-drafts] Rewrite section on ack range limiting (#3315)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Some suggestions, this is a hard section to rewrite.

> @@ -3202,27 +3202,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.
 
+

nit: extra line break?

> -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

This normative statement could be misleading.  A receiver really needs to limit the number of ranges somehow, otherwise ACK frames will grow in size indefinitely.  If you do keep it, I think its a SHOULD or MUST not a MAY.

> -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

This is a good point.  I think the most correct behavior is to prefer newly received packets, but larger packet numbers is simpler.

> -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.

I'd drop this sentence, but here's a suggestion if you keep it.

```suggestion
causing the sender to unnecessarily retransmit information.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3315#pullrequestreview-337843904