From 2719b297f7f12368ec12c8fdbf70aba6a2c2eb93 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 28 Oct 2020 10:27:59 +1100 Subject: [PATCH 1/3] Stop using initial timeout 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. --- draft-ietf-quic-recovery.md | 5 +++-- draft-ietf-quic-transport.md | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 2148949646..e5ca120497 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -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 +results in handshakes starting with a PTO of 1 second, as recommended in +{{?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 diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b242445ee7..4113c4b206 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2254,11 +2254,11 @@ 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: +current Probe Timeout (PTO) or the PTO for the new path (that is, using +kInitialRtt as defined in {{QUIC-RECOVERY}}) is RECOMMENDED. That is: ~~~ - validation_timeout = max(3*PTO, 6*kInitialRtt) + validation_timeout = 3*max(PTO_current, PTO_new) ~~~ This timeout allows for multiple PTOs to expire prior to failing path From ec9355809d26c1a62fcf6c6b565c0e477d69a49d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 28 Oct 2020 11:39:50 +1100 Subject: [PATCH 2/3] Remove formula with confusing variables --- draft-ietf-quic-transport.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4113c4b206..8c12311c5b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2255,11 +2255,7 @@ 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 PTO for the new path (that is, using -kInitialRtt as defined in {{QUIC-RECOVERY}}) is RECOMMENDED. That is: - -~~~ - validation_timeout = 3*max(PTO_current, PTO_new) -~~~ +kInitialRtt as defined in {{QUIC-RECOVERY}}) is RECOMMENDED. 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 From a9d9aeb75f339408c1481c0bb5e1e048f16957f6 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 30 Oct 2020 11:00:24 +1100 Subject: [PATCH 3/3] initial RTO comparison Co-authored-by: Jana Iyengar --- draft-ietf-quic-recovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index e5ca120497..7c17542a35 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -633,8 +633,8 @@ 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. This -results in handshakes starting with a PTO of 1 second, as recommended in -{{?RFC6298}}. +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