Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACKs for receiver-only #1232

Closed
ekr opened this issue Mar 18, 2018 · 5 comments
Closed

ACKs for receiver-only #1232

ekr opened this issue Mar 18, 2018 · 5 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects

Comments

@ekr
Copy link
Collaborator

ekr commented Mar 18, 2018

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

But this isn't true if the counterparty piggybacks ACKs in its packets that contain STREAM data (which is at least what I do!), and why I filed #1231. Is this really the behavior we want?

@nibanks
Copy link
Member

nibanks commented Mar 18, 2018

@ekr, I don't understand why you say this isn't true. The issue here is that if an endpoint sends nothing but ACKs, there is no guarantee its peer will acknowledge those packets. The peer may have other data to send back, and may choose to include ACK frames in those packets, if there is room, but if the peer has enough constant stream data to send back and (for some reason) prioritizes the STREAM frames higher than ACK frames, it might not end up acknowledging the endpoint's ACK frames in a timely manner.

All that being said, personally I think ACK frames should have the highest priority when framing a packet to send out. So if you ever have something to send out (other than the ACKs) then the ACKs should end up getting sent too. But all this seems like an implementation issue to me.

@ekr
Copy link
Collaborator Author

ekr commented Mar 19, 2018

Sorry, what's not true is the claim that you "will not". I agree you "may not". The distinction here is only relevant because of PR#1231, in which case you really would not.

@martinthomson
Copy link
Member

So the more that I think about the problem here, the more I think that it was intended to address a non-problem.

The problem it was written to address was an asymmetric sending arrangement, but realistically, the endpoint generating data in that scenario will likely generate ACK frames as it goes.

Encouraging the sending of PING frames here is more likely to cause problems than solve them.

Maybe the right answer here is to remove this paragraph entirely.

@ekr
Copy link
Collaborator Author

ekr commented Mar 19, 2018

I updated #1231 to rewrite this graph in a less normative sense.

@mnot mnot added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Mar 28, 2018
@mnot mnot added this to Reliability in QUIC May 23, 2018
@martinthomson
Copy link
Member

Closed by #1231.

@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
No open projects
QUIC
Reliability
Development

No branches or pull requests

4 participants