On 6/10/2023 4:32 PM, Zaheduzzaman Sarker wrote:
On Sat, Jun 10, 2023 at 1:13 AM Kazuho Oku <kazuho...@gmail.com> wrote:
2023年6月7日(水) 22:20 RFC Errata System <rfc-edi...@rfc-editor.org>:
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 <pluk...@nginx.com>
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
