tree 7c9334a5d411ce8bbfcfbcc5c4d139e9f5b8a01c
parent 1a3120f3fd7696e9f27243bba88fe06d62221f0e
author Victor Boivie <boivie@webrtc.org> 1713956442 +0200
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> 1714031604 +0000

dcsctp: Compute RTO with higher precision

Since the code measuring the RTT has been converted to using TimeDelta
which internally stores the duration in microseconds, from DurationMs
which uses milliseconds, the RTO calculation can use the higher
precision to calculate lower non-zero durations on really fast networks
such within a data center.

Before this CL, which is from the initial drop of dcSCTP, the RTO
calculation was done using the algorithm from the paper "V. Jacobson:
Congestion avoidance and control", but now we're using the original
algorith from https://tools.ietf.org/html/rfc4960#section-6.3.1, which
comes from https://datatracker.ietf.org/doc/html/rfc6298#section-2.

Two issues were found and corrected:
 1. The min RTT variance that is specified in the config file was
    previously incorrectly divided by 8. That was not its intention,
    but we're keeping that behaviour as other clients have actually
    measured a good value to put there. This represents "G" in
    the "basic algorithm" above, and since that is multiplied with K,
    which is four, the default value of 220 wouldn't make sense if it
    wasn't scaled down, as that would make the RTO easily saturate to
    the RTO_max (800ms).
 2. The previous algorithm had large round-off errors (probably because
    the code used milliseconds), which makes fairly big changes to the
    calculated RTO in some situations.

Bug: webrtc:15593
Change-Id: I95a3e137c2bbbe7bf8b99c016381e9e63fd01d87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349000
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42170}