Re: [quicwg/base-drafts] Add more context and text around ACK frequency (#3706)

[ianswett <[e-mail]>]

@ianswett commented on this pull request.



> -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.  An
-endpoint MUST NOT send a non-ack-eliciting packet in response to a
-non-ack-eliciting packet, 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.
-However, the endpoint acknowledges non-ACK-eliciting packets when it sends an
-ACK frame.
+### Acknowledgement Frequency
+
+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff.
+
+Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending

I would still like to be clearer here and I don't really like "sending rate" in the context of window-based controllers.  I made some specific suggestions before.  Can you take another look at them?

> -one ACK-frame-only packet in response to receiving an ack-eliciting packet.  An
-endpoint MUST NOT send a non-ack-eliciting packet in response to a
-non-ack-eliciting packet, 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.
-However, the endpoint acknowledges non-ACK-eliciting packets when it sends an
-ACK frame.
+### Acknowledgement Frequency
+
+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff.
+
+Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.

```suggestion
rate. In both cases, delaying acknowledgments can adversely affect performance.
```

> -received packet. Limiting ACK frames avoids an infinite feedback loop of
-acknowledgements, which could prevent the connection from ever becoming idle.
-However, the endpoint acknowledges non-ACK-eliciting packets when it sends an
-ACK frame.
+### Acknowledgement Frequency
+
+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. This determination involves a tradeoff.
+
+Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.
+
+On the other hand, reducing the frequency of packets that carrying only
+acknowledgements reduces packet processing cost at both endpoints. It can also

Q: Doesn't it reduce packet serialization and sending costs at the receiver and packet processing costs at the sender?  In practice, the cost of sending ACK-only packets is commonly worse, so it seems worth mentioning.

> +control purposes {{QUIC-RECOVERY}}. Sending only PADDING frames might cause the
+sender to become limited by the congestion controller with no acknowledgments
+forthcoming from the receiver. Therefore, a sender SHOULD ensure that other
+frames are sent periodically in addition to PADDING frames to elicit
+acknowledgments from the receiver.

I'd remove "necessarily" from your suggestion, but otherwise LGTM.

-- 
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/3706#pullrequestreview-421546265