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

Stop using initial timeout #4263

Merged
merged 3 commits into from Nov 3, 2020
Merged

Stop using initial timeout #4263

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2719b29
Stop using initial timeout
martinthomson Oct 27, 2020
ec93558
Remove formula with confusing variables
martinthomson Oct 28, 2020
a9d9aeb
initial RTO comparison
martinthomson Oct 30, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 3 additions & 2 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -632,8 +632,9 @@ in most cases and is less likely to spuriously retransmit data.

Resumed connections over the same network MAY use the previous connection's
final smoothed RTT value as the resumed connection's initial RTT. When no
previous RTT is available, the initial RTT SHOULD be set to 333ms, resulting in
a 1 second initial timeout, as recommended in {{?RFC6298}}.
previous RTT is available, the initial RTT SHOULD be set to 333ms. This
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the existing text to the updated text. Is there something you're adding that is important?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"initial timeout" seems to be a concept that doesn't exist in 6298, but it seems to be implied something. And it is not defined. So I wanted to remove it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I forgot... The PTO is 3*kInitialRtt only for the handshake. A new path will be after the handshake is complete, so the value will have max_ack_delay added.

results in handshakes starting with a PTO of 1 second, as recommended
for TCP's initial retransmission timeout; see Section 2 of {{?RFC6298}}.

A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a
PATH_RESPONSE to set the initial RTT (see kInitialRtt in
Expand Down
8 changes: 2 additions & 6 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2254,12 +2254,8 @@ abandons its attempt to validate the path.
Endpoints SHOULD abandon path validation based on a timer. When setting this
timer, implementations are cautioned that the new path could have a longer
round-trip time than the original. A value of three times the larger of the
current Probe Timeout (PTO) or the initial timeout (that is, 2*kInitialRtt) as
defined in {{QUIC-RECOVERY}} is RECOMMENDED. That is:

~~~
validation_timeout = max(3*PTO, 6*kInitialRtt)
~~~
current Probe Timeout (PTO) or the PTO for the new path (that is, using
kInitialRtt as defined in {{QUIC-RECOVERY}}) is RECOMMENDED.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add the computation back in? With the corrected values of course:

That is, validation timeout = max(3*PTO, 9*kInitialRtt)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that is wrong. Because the PTO on the new path is 9*kInitialRtt on the handshake, but 9*kInitialRtt + 3*max_ack_delay on migration.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh hm. It's actually more than that, since rttvar is also set to kInitialRtt/2 initially. Ok, let's leave it as you have it then.


This timeout allows for multiple PTOs to expire prior to failing path
validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame
Expand Down