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. //Zahed >
