I have mixed feelings about fixed constants in general, but I agree that referencing the 60 second max in RFC6298 seems reasonable.
I'm not sure it's worth an errata, but if we were still in the editing process, I suspect we would have accepted a sentence mentioning that. Thanks, Ian On Sat, Oct 15, 2022 at 9:09 PM Cordeiro, Cliff <[email protected]> wrote: > 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 > >
