Stop using initial timeout #4263
Conversation
Address validation can use 3*PTO, just taking the maximum of the old and new path PTO. The idea of initial timeout is easily replaced in recovery by instead describing the effect on the PTO. The net effect is the same, except that new paths often have to include the maximum ACK delay, which this doesn't incorporate. Closes #4261. Closes #4262.
martinthomson
added
editorial
| @@ -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 | |||
There was a problem hiding this comment.
I prefer the existing text to the updated text. Is there something you're adding that is important?
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
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.
draft-ietf-quic-transport.md
Outdated
|
|
||
| ~~~ | ||
| validation_timeout = max(3*PTO, 6*kInitialRtt) | ||
| validation_timeout = 3*max(PTO_current, PTO_new) |
There was a problem hiding this comment.
PTO_current and PTO_new aren't defined, so even thought I understand the intent, I'm no longer sure this pseudocode is helpful. Possibly it'd be better to remove it?
There was a problem hiding this comment.
That is probably good. I will do that.
| 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. |
There was a problem hiding this comment.
Can we add the computation back in? With the corrected values of course:
That is, validation timeout = max(3*PTO, 9*kInitialRtt)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
There was a problem hiding this comment.
I think this is correct. LGTM, but waiting for @ianswett to take a look.
Address validation can use 3*PTO, just taking the maximum of the old and
new path PTO. The idea of initial timeout is easily replaced in
recovery by instead describing the effect on the PTO. The net effect is
the same, except that new paths often have to include the maximum ACK
delay, which this doesn't incorporate.
Closes #4261.
Closes #4262.