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 <[email protected]> wrote: > > > On 6/10/2023 4:32 PM, Zaheduzzaman Sarker wrote: > > On Sat, Jun 10, 2023 at 1:13 AM Kazuho Oku <[email protected]> wrote: > > > >> > >> 2023年6月7日(水) 22:20 RFC Errata System <[email protected]>: > >> > >>> 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 <[email protected]> > >>> > >>> 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 >
