Re: [quicwg/base-drafts] Restrict ACK-clocking to ACK-only frames. (#1231)

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.

I'm not sure I really I understand the problem you're trying to solve.
If you really want to send duplicate ACK frames (without receiving any new packets, and without any timer expiring), the change of the first sentence in your PR would be sufficient.

>  
 To limit ACK blocks to those that have not yet been received by the sender, the
 receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once
 an ACK frame has been acknowledged, the packets it acknowledges SHOULD NOT be
 acknowledged again.
 
-A receiver that is only sending ACK frames will not receive acknowledgments for
-its packets.  Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is
-received will ensure that acknowledgements are generated by a peer.  Otherwise,
-an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment.
+Because ACK-only packets are not acknowledged, a receiver that is only
+sending ACK frames will only receive acknowledgements for its packets
+if the sender piggybacks them on other packets. In order to enable

Why does it play a role how the sender bundles frames into packets?

>  
 To limit ACK blocks to those that have not yet been received by the sender, the
 receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once
 an ACK frame has been acknowledged, the packets it acknowledges SHOULD NOT be
 acknowledged again.
 
-A receiver that is only sending ACK frames will not receive acknowledgments for
-its packets.  Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is
-received will ensure that acknowledgements are generated by a peer.  Otherwise,
-an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment.
+Because ACK-only packets are not acknowledged, a receiver that is only
+sending ACK frames will only receive acknowledgements for its packets
+if the sender piggybacks them on other packets. In order to enable
+this, senders SHOULD prioritize sending ACKs along with their data.

I don't think you should prioritize ACKs, if the ACKs don't ack any new retransmittable packets.

>  
 To limit ACK blocks to those that have not yet been received by the sender, the
 receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once
 an ACK frame has been acknowledged, the packets it acknowledges SHOULD NOT be
 acknowledged again.
 
-A receiver that is only sending ACK frames will not receive acknowledgments for
-its packets.  Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is
-received will ensure that acknowledgements are generated by a peer.  Otherwise,
-an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment.
+Because ACK-only packets are not acknowledged, a receiver that is only
+sending ACK frames will only receive acknowledgements for its packets
+if the sender piggybacks them on other packets. In order to enable
+this, senders SHOULD prioritize sending ACKs along with their data.
+In addition, if a receiver regularly issues additional flow control
+credit rather than just issuing infinite flow control credit at the

Issuing infinite flow control credit is a really bad idea. I don't think we should mention this as an option 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/1231#pullrequestreview-104894712