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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

This seems to be heading in a good direction, thanks for working on it.

> +Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.

```suggestion
Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to open up congestion window,
allowing more packets to be sent, as well as increase the congestion window. In both
cases, delaying acknowledgments can adversely affect performance.
```

> -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 however.
+
+Endpoints rely on timely acknowledgment to detect loss; see Section X of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section X 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 acknowledgement packets reduces

Do you mean ACK-only packets?  Otherwise this could be read to include ACK frames bundled with data, which I don't believe is the intent.

> +Endpoints rely on timely acknowledgment to detect loss; see Section X of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section X 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 acknowledgement packets reduces
+packet processing cost at both endpoints. It can also improve connection
+throughput on severely asymmetric links; see Section 3 of {{?RFC3449}}.
+
+A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting
+packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and
+consistent with recommendations for TCP endpoint behavior {{?RFC5681}}.
+
+A receiver MAY process multiple packets before sending any ACK frames in

```suggestion
A receiver MAY process multiple available packets before determining whether to sending an ACK frame in
```

> +response. This allows for a receiver to process packets already queued for
+processing before determining whether to send an acknowledgement.

```suggestion
response.
```

> +packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and

```suggestion
packets. Knowledge of how frequently the peer's congestion controller needs feedback,
network conditions or further research and experimentation might suggest alternative
acknowledgment strategies with better performance characteristics. This
recommendation is general in nature and
```

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