Re: [quicwg/base-drafts] Clarify ACK of ACKs and bundling a PING (#2794)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Some tweaks, but this is good.

> @@ -2859,13 +2859,16 @@ valid frames? -->
 
 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are

Is this section missing an intro?

> An endpoint sends an ACK frame to indicate that it has received and processed packets.  Sending ACK frames is the primary mechanism for advancing the state of a connection.

Happy to take this to another issue...

> @@ -2859,13 +2859,16 @@ valid frames? -->
 
 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are
+limits on how frequently they can be sent.  An endpoint MUST NOT send more than
+one packet containing only an ACK frame per received ACK-eliciting packet
+(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT
+send a packet containing only an ACK frame in response to a non-ACK-eliciting
+packet (one containing only ACK and/or PADDING frames), even if there are
+packet gaps which precede the received packet. This prevents an indefinite

```suggestion
packet gaps which precede the received packet. Limiting the sending of ACK
frames avoids creating an indefinite feedback loop of acknowledgements,
which could prevent the connection from ever becoming idle.
```
Apologies for the multi-line suggestion.

> @@ -2883,16 +2886,21 @@ needing acknowledgement are received.  The sender can use the receiver's
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
 
+An endpoint that is only sending acknowledgements will not receive
+acknowledgments from its peer unless those acknowledgements are included in
+packets with ACK-eliciting frames.  A sender SHOULD bundle ACK frames with
+other frames when possible.

Maybe instead:

> Though it sending an ACK frame in every packet can be inefficient, a sender SHOULD send ACK frames in ACK-eliciting packets that it sends.

Which leads to a difficult question: how often do you send an ACK frame when you aren't receiving ACK-eliciting packets?  We've agreed to make it possible to use the specs to build an "decently performant" stack.  Is this a point that isn't important, or is there a need for specific advice?



-- 
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/2794#pullrequestreview-254370629