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

Verification of RTO no longer necessary #2168

Closed
janaiyengar opened this issue Dec 13, 2018 · 1 comment
Closed

Verification of RTO no longer necessary #2168

janaiyengar opened this issue Dec 13, 2018 · 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

@janaiyengar
Copy link
Contributor

janaiyengar commented Dec 13, 2018

The changes to loss recovery in #1974 allow for some simplification in RTO response. The recovery draft says about an ACK after an RTO (in Section 5.3.3):

When an ACK is received that acknowledges only one or more packets sent on an
RTO event, all unacknowledged packets with lower packet numbers MUST be marked
as lost. If packets sent prior to the first RTO are acknowledged in the same ACK, the
RTO is considered spurious and standard loss detection rules apply.

If the ACK acknowledges only packets sent after an RTO, everything sent earlier is marked lost. With time-threshold loss detection in #1974, that is exactly what standard loss detection will do. As a result, in both the conditions described in the text quoted above, standard loss detection does the right thing.

We can remove the two cases (remove OnRetransmissionTimeoutVerified) and always simply use standard loss detection when an ACK is received.

@janaiyengar janaiyengar added design An issue that affects the design of the protocol; resolution requires consensus. -recovery labels Dec 13, 2018
@janaiyengar
Copy link
Contributor Author

Closed by #2114.

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

No branches or pull requests

2 participants