Fix RTT estimation when timestamp option is enabled.

From RFC7323#Section-4

The [RFC6298] RTT estimator has weighting factors, alpha and beta, based on an
implicit assumption that at most one RTTM will be sampled per RTT.  When
multiple RTTMs per RTT are available to update the RTT estimator, an
implementation SHOULD try to adhere to the spirit of the history specified in
[RFC6298].  An implementation suggestion is detailed in Appendix G.

From RFC7323#appendix-G
Appendix G.  RTO Calculation Modification

   Taking multiple RTT samples per window would shorten the history calculated
   by the RTO mechanism in [RFC6298], and the below algorithm aims to maintain a
   similar history as originally intended by [RFC6298].

   It is roughly known how many samples a congestion window worth of data will
   yield, not accounting for ACK compression, and ACK losses.  Such events will
   result in more history of the path being reflected in the final value for
   RTO, and are uncritical.  This modification will ensure that a similar amount
   of time is taken into account for the RTO estimation, regardless of how many
   samples are taken per window:

      ExpectedSamples = ceiling(FlightSize / (SMSS * 2))

      alpha' = alpha / ExpectedSamples

      beta' = beta / ExpectedSamples

   Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs".

   Instead of using alpha and beta in the algorithm of [RFC6298], use alpha' and
   beta' instead:

      RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'|

      SRTT <- (1 - alpha') * SRTT + alpha' * R'

      (for each sample R')

PiperOrigin-RevId: 213644795
Change-Id: I52278b703540408938a8edb8c38be97b37f4a10e

0 files changed, 0 insertions, 0 deletions