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

Remove Requirement of an Acknowledgement per Round Trip #3030

Closed
nibanks opened this issue Sep 13, 2019 · 3 comments · Fixed by #3055
Closed

Remove Requirement of an Acknowledgement per Round Trip #3030

nibanks opened this issue Sep 13, 2019 · 3 comments · Fixed by #3055
Assignees
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.

Comments

@nibanks
Copy link
Member

nibanks commented Sep 13, 2019

The spec gives no reason (that I can see) as to why an ACK frame must be sent at least once per round trip (assuming there are ack-eliciting packets to acknowledge), effectively overwriting the ACK delay logic when the RTT is very small. If the RTT is smaller than the platform's timer granularity, this isn't really even possible.

I propose to remove this requirement. If the WG instead feels that we should keep this requirement, then there should be a reasoning for it; and probably an update to the PTO calculation as well.

@ianswett
Copy link
Contributor

ianswett commented Sep 13, 2019

As I commented on the PR that this came up in, given we have an explicit max_ack_delay that's now communicated, removing the 1 ACK per RTT requirement seems wise.

TCP has no such recommendation and I'm unaware of any indications or proposals that it should have such a property.

@janaiyengar
Copy link
Contributor

@nibanks's point that the RTT can be smaller than the platform's granularity is a good one. I agree that this text ought to be removed.

@ianswett
Copy link
Contributor

This is changing text in a SHOULD statement, so I believe it should be marked as design.

@martinthomson martinthomson added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Sep 24, 2019
@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Sep 25, 2019
@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Oct 15, 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
None yet
Development

Successfully merging a pull request may close this issue.

5 participants