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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Thanks Jana, I accepted or integrated variations on all your suggestions except one.

> @@ -2859,13 +2859,21 @@ 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.
+An endpoint sends ACK frames to acknowledge packets it has received and
+processed. Sending ACK frames is the primary mechanism for advancing the state
+of a connection.

Agreed, removed.

> @@ -2874,6 +2882,18 @@ sender to become limited by the congestion controller (as described in
 receiver. Therefore, a sender SHOULD ensure that other frames are sent in
 addition to PADDING frames to elicit acknowledgments from the receiver.
 
+An endpoint that is only sending acknowledgements will not receive
+acknowledgments from its peer unless those acknowledgements are included in

Isn't the existing text more accurate(minus the sender/endpoint change)?

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

The existing text follows what TCP does as closely as I can manage, which I think is the best prior art we can follow here.

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