This is very helpful. Thank you, Dr. Fairhurst. I do see that 9002 refers to the RTO calculation in 6298. I will try to get a maximum configuration value added to the library I use (with a lower limit of 60 seconds).
Cliff Cordeiro ________________________________ From: Gorry Fairhurst <[email protected]> Sent: Saturday, October 15, 2022 12:47:27 AM To: Cordeiro, Cliff <[email protected]>; [email protected] <[email protected]> Subject: Re: truncating exponential backoff in loss timer [Warning] This email comes from an external source. Be careful of any embedded links and attachments. On 14/10/2022 21: 06, Cordeiro, Cliff wrote: Hi, The loss timer as defined in RFC 9002 A. 8 has an exponential backoff component “* (2 ^ pto_count)” that is unbounded. This means that if there is a lengthy network outage, QUIC may not recover ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. ZjQcmQRYFpfptBannerEnd On 14/10/2022 21:06, Cordeiro, Cliff wrote: Hi, The loss timer as defined in RFC 9002 A.8 has an exponential backoff component “* (2 ^ pto_count)” that is unbounded. This means that if there is a lengthy network outage, QUIC may not recover until up to twice the length of the outage because it will wait for the timer to expire and the timer doubles without bound. For example, a network outage of one minute could translate into a QUIC “outage” of two (on average) to three minutes (unlucky upper bound). I think there should be a limit to the loss timer. I don’t know if the spec should provide a specific limit but I think it should be allowable to set an upper bound on the loss timer in the 8-64 second rage. Thank you for your consideration. Cliff Cordeiro RFC 8961 provides Best Current Practice with high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. https://datatracker.ietf.org/doc/rfc8961/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc8961/__;!!FxRPhOnl!_rawDXDK2FMCwattYKhv_JBg9CyBdJ8y1sNTZ_N6QMCjKhA8iLLXAcWIo7eNIq-agZzbrOyEGw0RCIGwhWTLLrxe$> It refers to RFC6298, and states: A maximum value MAY be placed on the RTO. The maximum RTO MUST NOT be less than 60 seconds (as specified in [RFC6298]). Gorry
