Re: [Technical Errata Reported] RFC9002 (7539)

[Kazuho Oku <[e-mail]>]

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.



>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9002 (draft-ietf-quic-recovery-34)
> --------------------------------------
> Title               : QUIC Loss Detection and Congestion Control
> Publication Date    : May 2021
> Author(s)           : J. Iyengar, Ed., I. Swett, Ed.
> Category            : PROPOSED STANDARD
> Source              : QUIC
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
>
>

-- 
Kazuho Oku