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.

Sign up for GitHub

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

Jump to bottom

Transmitting ACK frames #601

Closed
gloinul opened this issue Jun 7, 2017 · 1 comment
Closed

Transmitting ACK frames #601

gloinul opened this issue Jun 7, 2017 · 1 comment
Labels
-recovery 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

@gloinul
Copy link
Contributor

gloinul commented Jun 7, 2017

Raised on draft-ietf-quic-recovery-03

I find nothing discussing the transmission of ACK Frame in the recovery draft. It includes process for how to process the received, including delayed ACK transmission using default 25 ms, but their is no specification regarding how and when the delayed ACK transmission should be used, and how often in relation to received packets a peer should transmit ACK frames.

I also do not find these details in the transport-03 draft. But, I think they actually belong here, as ACK thinning for high rates as well as timed delayed ACK is primarily functions for loss recovery and congestion control behavior beyond the initial handshake.
@martinthomson martinthomson added -recovery design An issue that affects the design of the protocol; resolution requires consensus. labels Jun 20, 2017
@martinthomson martinthomson changed the title Recovery: Specification of transmission of ACK frames Specification of transmission of ACK frames Jun 20, 2017
@mnot mnot added this to ACK Frame in QUIC Jun 20, 2017
@mnot mnot changed the title Specification of transmission of ACK frames Transmitting ACK frames Jun 20, 2017
@mnot mnot moved this from ACK Frame to Reliability in QUIC Jun 21, 2017
@mnot mnot mentioned this issue Jun 21, 2017
Closed
@mnot
Copy link
Member

mnot commented Jun 21, 2017

Dup of #230.

@mnot mnot closed this as completed Jun 21, 2017
@mnot mnot removed this from Reliability in QUIC Jun 21, 2017
@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
Assignees
No one assigned
Labels
-recovery 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
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinthomson @mnot @gloinul