Re: [Technical Errata Reported] RFC9002 (7539)

[Ian Swett <[e-mail]>]

I agree this is an error in RFC9002.

Christian's suggestion is a good one, but I think it requires some
experimentation to understand what variance estimator would perform well in
practice.  We conducted a few experiments that used stdev and they didn't
perform better in the metrics we were tracking, unfortunately.

Ian

On Sun, Jun 11, 2023 at 10:08 PM Christian Huitema <[e-mail]>
wrote:

>
>
> On 6/10/2023 4:32 PM, Zaheduzzaman Sarker wrote:
> > On Sat, Jun 10, 2023 at 1:13 AM Kazuho Oku <[e-mail]> wrote:
> >
> >>
> >> 2023年6月7日(水) 22:20 RFC Errata System <[e-mail]>:
> >>
> >>> The following errata report has been submitted for RFC9002,
> >>> "QUIC Loss Detection and Congestion Control".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> https://www.rfc-editor.org/errata/eid7539
> >>>
> >>> --------------------------------------
> >>> Type: Technical
> >>> Reported by: Sergey Kandaurov <[e-mail]>
> >>>
> >>> Section: 5.3
> >>>
> >>> Original Text
> >>> -------------
> >>> smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
> >>> rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
> >>> rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>> rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
> >>> rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
> >>> smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> Per Appendix A.7 of this RFC and Section 2 of the referred RFC 6298,
> >>> rttvar should be computed before updating smoothed_rtt itself.
> >>>
> >>
> >> To me it seems the errata is valid; in fact, quicly conforms to the
> >> "corrected" logic.
> >>
> >> Fortunately, the difference between the two logic seems small to me; in
> >> the original approach, rttvar will be 7/8 of the correct value. RTT
> >> estimates are going to differ among the implementations anyway (due to
> >> e.g., how frequently they are updated between transport protocols, ACK
> >> coalescing, etc.), so my humble guess is that 7/8 would not cause any
> >> issues.
> >>
> >
> > Thanks Kazuho. I have also got similar feedbacks from other implementers.
> > Based on this I will change the errata status to verified.
>
> I agree with Kazuho on this specific issue. This is indeed an errata.
>
> There is more to say about this all subject. Our RFCs are mechanically
> reproducing the algorithm designed by Van Jacobson in 1988. At the time,
> there was a premium on using as few instructions as possible, which
> means constraints in the algorithm design. For example, the formula in
> RFC 6298
>
> RTO = SRTT + max (G, K*RTTVAR)
> with K = 4
>
> is designed to ensure that the RTO only fires if the packet has a high
> probability of being lost. If the RTT distribution was Gaussian and the
> SRTT and RTTVAR represented the actual long term average and standard
> deviation, this would be a "4 sigma" probability, which is very low
> indeed. However:
>
> * the average of absolute differences is only an approximation of the
> standard deviation.
> * the delay distribution is not gaussian
> * the successive delay measurements are often highly correlated
> * because of correlation, too frequent RTT measurements cause the
> smoothed RTT to closely track the current RTT, and the RTTVAR to quickly
> trend to zero
>
> Maybe we should consider deprecating this old formula. After all, RACK
> does not really need it. Even if it did, there are measurements that are
> more robust, such as average or maximum over a sliding window of N RTT,
> or maybe over N congestion control epochs, with N depending on the
> congestion control algorithm.
>
> -- Christian Huitema
>