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

Recovery-31: Initial Smoothed_RTT values #4192

Closed
gloinul opened this issue Oct 12, 2020 · 3 comments · Fixed by #4213
Closed

Recovery-31: Initial Smoothed_RTT values #4192

gloinul opened this issue Oct 12, 2020 · 3 comments · Fixed by #4213
Labels
-recovery editorial An issue that does not affect the design of the protocol; does not require consensus. ietf-lc An issue that was raised during IETF Last Call.

Comments

@gloinul
Copy link
Contributor

gloinul commented Oct 12, 2020

In Section 5.3:

"When there are no samples for a network path, and on the first RTT sample for the network path:

smoothed_rtt = rtt_sample
rttvar = rtt_sample / 2

Before any RTT samples are available, the initial RTT is used as rtt_sample. On the first RTT sample for the network path, that sample is used as rtt_sample. This ensures that the first measurement erases the history of any persisted or default values."

First of all this text uses "rtt_sample" while other places with the exception of the pseudo code uses latest_rtt variable. There are two issues with that. First that the value of rtt_sample is state dependent. If there exist an latest_rtt then that is used, if not the initial rtt. As the initial RTT is defined in Section 6.2.2 I think a forward reference is in place.

Finally, should this calculation in cases where latest_rtt exists be using min_ack_delay?

@gloinul gloinul changed the title Initial Smoothed_RTT values Recovery-31: Initial Smoothed_RTT values Oct 12, 2020
@gloinul
Copy link
Contributor Author

gloinul commented Oct 12, 2020

I like to add that there are some structural issues in Section 6.2.1 and 6.2.2 where the initial value depends on both section.

@larseggert larseggert added the ietf-lc An issue that was raised during IETF Last Call. label Oct 13, 2020
@larseggert larseggert added this to Triage in Late Stage Processing via automation Oct 13, 2020
@larseggert
Copy link
Member

Based on #4213, labeling this as "editorial"

@larseggert larseggert added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Oct 15, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Oct 15, 2020
@gloinul
Copy link
Contributor Author

gloinul commented Oct 15, 2020

The PR resolves this issue.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-recovery editorial An issue that does not affect the design of the protocol; does not require consensus. ietf-lc An issue that was raised during IETF Last Call.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

3 participants