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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

This is a little too strong in its current form, I think.

> @@ -3413,17 +3421,10 @@ Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in
 the IP header SHOULD be acknowledged immediately, to reduce the peer's response
 time to congestion events.
 
-As an optimization, a receiver MAY process multiple packets before sending any
-ACK frames in response.  In this case the receiver can determine whether an
-immediate or delayed acknowledgement should be generated after processing
-incoming packets.
-
-Packets containing PADDING frames are considered to be in flight for congestion
-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 in addition to PADDING frames to elicit acknowledgments from
-the receiver.
+The algorithms in {{QUIC-RECOVERY}} are resilient to receivers that do not

do we want to add "generally" to "resilient"?  Or, "in principle"?  Or "in theory"?

> +which could prevent the connection from ever becoming idle. Note that
+non-ack-eliciting packets are eventually acknowledged when the endpoint sends an
+ACK frame in response to other events.

```suggestion
which could prevent the connection from ever becoming idle.
Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an
ACK frame in response to other events.
```

> +A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. Under normal circumstances, reducing the frequency of
+acknowledgement packets can improve connection and endpoint performance in
+several ways, such as reducing computational cost at both endpoints, and
+improving connection throughput on severely asymmetric links.

You need to phrase this more as a trade-off.  This is concentrated on the benefits of reducing acknowledgments.  But the introduction here also needs to recognize that generating acknowledgments in a timely fashion is critical for performance.

> -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. Under normal circumstances, reducing the frequency of
+acknowledgement packets can improve connection and endpoint performance in
+several ways, such as reducing computational cost at both endpoints, and
+improving connection throughput on severely asymmetric links.
+
+However, there are undesirable consequences to a receiver simply reducing the

If you balance the first paragraph out, then you don't need a "however" here.  You can just talk in more detail about the advantages of more frequent acknowledgment.

> +acknowledgement frequency, especially to an arbitrary fixed value. A sender
+relies on receipt of acknowledgements to determine the amount of data in flight
+and to detect loss; see {{QUIC-RECOVERY}}. Loss detection can be delayed with
+late acknowledgements. Window-based congestion controllers, such as the one
+defined in {{QUIC-RECOVERY}}, rely on receipt of acknowledgments to increase
+their sending rate. Consequently, a connection can suffer performance penalties

If you move the general statement at the end of this to the first paragraph, then you can probably shorten this paragraph to: 

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

We don't need the specific dig regarding the "arbitrary fixed value".

> +Further research and experimentation will yield effective mechanisms to balance
+this tradeoff. Meanwhile, this document provides the following guidance:
+{{sending-acknowledgements}}, a receiver SHOULD generate an ACK frame for at
+least every second ack-eliciting packet. This recommendation is in keeping with

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

> @@ -3555,6 +3566,16 @@ messages are delayed or lost.  Note that the same limitation applies to other
 data sent by the server protected by the 1-RTT keys.
 
 
+### Other Considerations

I'm sure that we can do better than "Other Considerations" here.

```suggestion
### PADDING Frames Consume Congestion Window
```

> @@ -3555,6 +3566,16 @@ messages are delayed or lost.  Note that the same limitation applies to other
 data sent by the server protected by the 1-RTT keys.
 
 
+### Other Considerations
+
+Packets containing PADDING frames are considered to be in flight for congestion
+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 in addition to PADDING frames to elicit acknowledgments from

```suggestion
frames are sent periodically in addition to PADDING frames to elicit acknowledgments from
```

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