Internet DRAFT - draft-jovev-tsvwg-sctp-rto

draft-jovev-tsvwg-sctp-rto






Internet Engineering Task Force                                 D. Jovev
Internet-Draft                                                M. Proshin
Intended status: Standards Track                                Ericsson
Expires: November 10, 2019                                   May 9, 2019


                Determining SCTP's Retransmission Timer
                     draft-jovev-tsvwg-sctp-rto-04

Abstract

   This document defines a modification in the RFC 4960 [RFC4960]
   defined Stream Control Transmission Protocol's (SCTP's)
   Retransmission Timer (RTO) calculation method.

   The modification is aimed to reduce the frequency of spurious T3
   timeouts, which are caused by underestimated RTO values, derived by
   the [RFC4960] defend RTO calculation method.  The proposed
   modification aligns the RTO calculation method with the
   characteristics of the statistical estimator algorithms, which are
   used for SRTT and RTTVAR calculation, the SCTP protocol data transfer
   rules and the characteristics of the data packets' arrival pattern in
   the telecom signalling networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 10, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Jovev & Proshin         Expires November 10, 2019               [Page 1]

Internet-Draft                                                  May 2019


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Problem description . . . . . . . . . . . . . . . . . . . . .   3
   3.  The modified algorithm for RTO Calculation  . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Technical background for the modifications in the
                RTO calculation algorithm  . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Like TCP, the SCTP's reliable transfer of data is ensured by limiting
   the time in which the acknowledgement for the reception of the
   transmitted data is received, after which expiration all
   unacknowledged data is retransmitted.  The duration of this timer is
   referred to as Retransmission Timeout (RTO) and the actual timer is
   called T3-rtx or just T3.

   The expiration of the T3 timer not only invokes retransmission of the
   unacknowledged data it also drastically reduces the congestion window
   (cwnd) to 1 MTU, which are both undesirable actions: data
   retransmission increases the amount of sent data in the network, and
   1 MTU cwnd drastically reduces the SCTP association transmission
   capacity.  Because of that, determining an RTO value which reflects
   the highest RTT, or the highest feedback time, as more appropriately
   called in [ALLMAN99], is critical for reducing the probability of
   spurious T3 timeouts, which is critically important for stable SCTP
   operation.

   Namely, while in the conventional file transfer applications the
   transport layer transmission capacity reduction, due to T3 timeouts,
   only prolongs the time for completion of the file transfer, in the
   telecom signalling networks it often results in false congestion
   i.e., congestion caused by SCTP transmission capacity reduction not



Jovev & Proshin         Expires November 10, 2019               [Page 2]

Internet-Draft                                                  May 2019


   by traffic increase, which can lead to unrepairable loss of data that
   adversely affects the services provided by the telecom networks.

   This document defines a modification in the [RFC4960] defined SCTP's
   Retransmission Timer (RTO) calculation method.  The modification is
   aimed to reduce the frequency of spurious T3 timeouts, which are
   caused by underestimated RTO values, by adjusting the RTO calculation
   method to the characteristics of the statistical estimator
   algorithms, which are used for SRTT and RTTVAR calculation, and to
   the SCTP protocol data transfer rules and the characteristics of the
   data packets' arrival pattern in the telecom signalling networks.

   The modified RTO calculation affects only the sender side and it does
   not require introduction of new protocol variables or parameters nor
   change of the [RFC4960] recommended values for the existing RTO
   related protocol parameters.

   The motivations for the modification in the [RFC4960] algorithm for
   RTO calculation are outlined in Section 2.  The actual modification
   in the [RFC4960] algorithm for RTO calculation is specified in
   Section 3 whereas the technical background for the modification is
   elaborated in the Appendix A.

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Problem description

   The [RFC4960] defined process for RTO determination consists of two
   steps.

   In the first step, using RTT measurements as input data, a calculated
   RTO value is derived from the mean/smooth RTT (SRTT) and RTT
   variation (RTTVAR) values, which are determined using a statistical
   estimator algorithm, originally published in [JAC88], and then, in
   the second step, the used RTO is determined as:

      RTO <- min(RTO.Max, max(calculated RTO, RTO.Min)),

   where RTO.Min and RTO.Max are configurable protocol parameters with
   [RFC4960] recommended values of 1 sec and 60 seconds.

   By applying the [RFC4960] RTO calculation rules, the RTO value that
   will be used for the T3 timer will be:




Jovev & Proshin         Expires November 10, 2019               [Page 3]

Internet-Draft                                                  May 2019


      *  The value of the RTO.Min - if the calculated RTO is below
         RTO.Min.

      *  The calculated RTO - if the calculated RTO is above RTO.Min but
         below RTO.Max.

      *  The value of the RTO.Max - if the calculated RTO is above
         RTO.Max.

   Diagram in Figure 1 illustrates the outcome of the above RTO
   determination rules.

       Used RTO
            ^
            |
   RTO.MAX  +. . . . . .+-----------------
            |          / .
            |         /  .
            |        /   .
            |       /    .
            |      /     .
   RTO.Min  +-----+      .
            |     .      .
            |     .      .
            |     .      .
            |     .      .
            +-----+------+--------------->
                                   Calculated RTO
              RTO.Min  RTO.Max

       Figure 1: Relation between the calculated and used RTO values

   The SCTP protocol has been operating in the telecom networks for more
   than fifteen years and spurious T3 timeouts have been one of the most
   frequently reported problems.

   The results of the analysis of the spurious T3 timeouts problems,
   reported from the operating networks, indicated that the spurious T3
   timeouts frequency increases when the SRTT value is closer to the
   RTO.Min value to the point where the association becomes unstable if
   the SRTT is longer than the RTO.Min value.  The analysis of these
   problems also showed that the reported spurious T3 timeouts problems
   were resolved only by increasing the RTO.Min value well above the
   SRTT value.

   The fact that the spurious T3 timeouts were successfully prevented
   only by setting the RTO.Min value considerably above the SRTT value,
   leads to conclusion that the RTO values, which are derived by the



Jovev & Proshin         Expires November 10, 2019               [Page 4]

Internet-Draft                                                  May 2019


   [RFC4960] defend rules, are inadequate for the RTT variation pattern
   in the telecom signalling networks.

   In other words, the fact that the SCTP association operation is
   stable only when the RTO.Min value is well above the SRTT value,
   makes the RTO calculation, which is specified by the [RFC4960]
   section 6.3.1. rules C1 C2 and C3, seemingly redundant.

   To help visualise the problem, let assume, hypothetically, that the
   packets transmission pattern consists of high packet rate sequences
   longer than 500 msec with, for example, 200 packets/sec, which
   separated by 50 to 80 ms "idle" gaps.  For such packet rate pattern,
   the statistical estimator algorithm for RTTVAR will produce a very
   low RTTVAR values, very likely well below 5 msec, because, during the
   long high packet rate sequences, the SACK delay will vary around 5
   msec due to packet rate of 200 packets/sec.

   Consequently, with the [RFC4960] RTO calculation rule:

           RTO <- max(SRTT + 4 * RTTVAR, RTO.Min),

   the RTO margin to absorb unexpected SACK delays, in this hypothetical
   case 50 to 80 msec due to the packet transmission gaps, is determined
   by the difference between the calculated RTO value and the measured
   (calculated) SRTT.

   Since in case of low RTTVAR values the RTO is determined by the
   RTO.Min parameter, the RTO margin will be equal to the difference
   between the RTO.Min and SRTT (RTO margin = RTO.Min - SRTT).  Thus, as
   illustrated in Figure 2, the [RFC4960] RTO calculation rules produce
   robust RTO values only when the SRTT is well below RTO.Min parameter
   value, which is the root cause of the problem.



















Jovev & Proshin         Expires November 10, 2019               [Page 5]

Internet-Draft                                                  May 2019


       RTO margin
            ^
            |
   RTO.Min  +
            | \
            |   \
            |     \
            |       \
            |         \
            |           \
            |             \
            +---------------+---------->
            0                         SRTT
                         RTO.Min

            Figure 2: Relation between the RTO margin and SRTT

   To rectify this anomaly, this document introduces modification in the
   [RFC4960] algorithm for RTO calculation.  The actual modification is
   specified in Section 3 and it includes only change in the use of the
   RTO.Min protocol parameter; the technical background for the
   modification is elaborated in the Appendix A.

3.  The modified algorithm for RTO Calculation

   The modified rules governing the computation of SRTT, RTTVAR and RTO
   are as follows:

      C1)  Until an RTT measurement has been made for a packet sent to
           the given destination transport address, set RTO to the
           protocol parameter 'RTO.Initial'.

      C2)  When the first RTT measurement R is made, set

           SRTT <- R,

           RTTVAR <- R/2, and

           RTO <- SRTT + max(4 * RTTVAR, RTO.Min).

      C3)  When a new RTT measurement R' is made, set

           RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|

           and

           SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'




Jovev & Proshin         Expires November 10, 2019               [Page 6]

Internet-Draft                                                  May 2019


           Note: The value of SRTT used in the update to RTTVAR is its
           value before updating SRTT itself using the second
           assignment.

           After the SRTT and RTTVAR computation, update RTO:

           RTO <- SRTT + max(4 * RTTVAR, RTO.Min).

      C4)  When data is in flight and when allowed by rule C5 below, a
           new RTT measurement MUST be made each round trip.
           Furthermore, new RTT measurements SHOULD be made no more than
           once per round trip for a given destination transport
           address.  There are two reasons for this recommendation:
           First, it appears that measuring more frequently often does
           not in practice yield any significant benefit [ALLMAN99];
           second, if measurements are made more often, then the values
           of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted
           so that SRTT and RTTVAR still adjust to changes at roughly
           the same rate (in terms of how many round trips it takes them
           to reflect new values) as they would if making only one
           measurement per round-trip and using RTO.Alpha and RTO.Beta
           as given in rule C3.  However, the exact nature of these
           adjustments remains a research issue.

      C5)  Karn's algorithm: RTT measurements MUST NOT be made using
           packets that were retransmitted (and thus for which it is
           ambiguous whether the reply was for the first instance of the
           chunk or for a later instance).

           IMPLEMENTATION NOTE: RTT measurements should only be made
           using a chunk with TSN r if no chunk with TSN less than or
           equal to r is retransmitted since r is first sent.

      C6)  A maximum value may be placed on RTO provided it is at least
           RTO.max seconds.

   There is no requirement for the clock granularity G used for
   computing RTT measurements and the different state variables, other
   than:

   G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <-
   G.

   Experience [ALLMAN99] has shown that finer clock granularities (<=
   100 msec) perform somewhat better than more coarse granularities.






Jovev & Proshin         Expires November 10, 2019               [Page 7]

Internet-Draft                                                  May 2019


4.  IANA Considerations

   This document does not create any new registries or modify the rules
   for any existing registries managed by IANA.

5.  Security Considerations

   This document does not add any security considerations to those given
   in [RFC4960].

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              September 2007, <https://tools.ietf.org/html/rfc4960>.

6.2.  Informative References

   [ALLMAN99]
              and SIGCOMM'99, "On Estimating End-to-End Network Path
              Properties", 1999, <https://ntrs.nasa.gov/archive/nasa/
              casi.ntrs.nasa.gov/20000004338.pdf>.

   [JAC88]    and , "Congestion Avoidance and Control", November 1988,
              <https://people.eecs.berkeley.edu/~sylvia/cs268/papers/
              congavoid.pdf>.

Appendix A.  Technical background for the modifications in the RTO
             calculation algorithm

   As indicated in Section 2, with the [RFC4960] RTO calculation rules,
   the frequency of spurious T3 timeouts increases when the SRTT value
   is close to the RTO.Min value to the point where, under heavy load,
   the association becomes unstable if the SRTT is longer than the
   RTO.Min value.

   The reasons for such outcome can be contributed to the following
   factors:

      a)  The characteristic of the statistical estimator algorithms for
          SRTT and RTTVAR calculation;




Jovev & Proshin         Expires November 10, 2019               [Page 8]

Internet-Draft                                                  May 2019


      b)  The anomalies in the distribution of the RTT measurement
          values caused by the [RFC4960] SACK generation rules,
          specifically, the delay of SACK sending; and

      c)  Inappropriate solution for protection against underestimated
          RTO values.

   The characteristics of the statistical estimator algorithms for SRTT
   and RTTVAR, which are the foundation for RTO calculation, are well
   known and widely investigated in terms of improving the outcome
   (reduction of spurious T3 timeouts) by adjustment of the statistical
   estimator algorithms' configurable parameters.  For example, the
   investigation results published in [ALLMAN99] indicate that lower
   gain factors RTO.Alpha and RTO.Beta, in the SRTT and RTTVAR
   calculations formulas, reduces the probability of computing a low RTO
   value that will result in T3 timeout.  The same source also states
   that lower spurious T3 timeouts probability is also achieved by
   increasing the RTTVAR component i.e., the value of the factor K in
   the RTO calculation formula:

      RTO <- SRTT + K * RTTVAR.

   This behaviour can be related to the well-known characteristic of the
   statistical estimator algorithms for SRTT and RTTVAR estimation,
   which can be described as follows: If the RTT measurements values
   converge to a single RTT value, the calculated RTTVAR converge to
   zero (0) and the calculated RTO converge to SRTT.  As a result, a
   relatively short sequence of moderately low RTT values, which are
   within the RTT values range, simultaneously lowers the SRTT and
   RTTVAR values to the point where the calculated RTO value is below
   the highest value in the RTT variation range, which may result in
   spurious T3 timeout if the next RTT is at the top of the RTT
   variation range.

   This 'problem' is further exacerbated by the SCTP protocol rules for
   sending SACK which allow SACK delay of up to 500 msec.  Namely, the
   SACK delay rules, combined with burst nature of the data packets'
   arrival pattern in the telecom signalling networks, drastically
   increase the jitteriness of the RTT measurements.  That, in turn,
   adversely affect the results obtained by statistical estimator
   algorithms for SRTT and RTTVAR calculations in terms of
   underestimated RTO values that are prone to spurious T3 timeouts.

   Obviously, and as proven in the operating networks, an RTO determined
   by application of rule C6, with an RTO.Min value in seconds,
   practically eliminates underestimated RTO values and with that the
   spurious T3 timeouts.  That is because the 1 second RTO will be well
   above the delay inserted by the terrestrial transport networks, which



Jovev & Proshin         Expires November 10, 2019               [Page 9]

Internet-Draft                                                  May 2019


   operate with latency below 100 msec, and because the SACK delay is
   also well below 1 second.

   However, an RTO value in seconds, coupled with the RTO back-off rule
   RTO <- RTO * 2, results in too long detection of remote endpoint
   failure or complete failure of the physical layer.  For example, with
   the [RFC4960] recommended RTO.Min of 1 second, RTO.Max of 60 seconds
   and Association.Max.Retrans of 4 attempts, the association closure
   time will be 31 seconds, which is an unacceptably long time that,
   under high load, can potentially destabilise the operation of the
   network.

   Namely, in the telecom networks where the client nodes are connected
   to redundant server nodes and where multiple load sharing SCTP
   associations are used between the nodes, a timely detection of the
   SCTP remote peer endpoint failure, or complete failure of the
   physical layer, is critical to enables failover to the redundant
   resources.

   Thus, instead of using an arbitrary long RTO defend by RTO.Min
   parameter, which practically makes the calculated RTO value by rules
   C1, C2 and C3 redundant, the RTO value should reflect, as close as
   possible, the real conditions in the network in terms of the time to
   transport the packets between two endpoints, the time delays induced
   by the SCTP protocol rules and to also include adequate additional
   time as protection against underestimated RTO values.  To achieve
   that, the subsequent paragraphs first analyse the characteristics of
   the RTT components and then specify a modified RTO calculation
   algorithm which is derived from the characteristics of the
   statistical estimator algorithms for SRTT and RTTVAR and the
   characteristics of the RTT components.

   Specifically, an RTT measurement starts at transmission of data, or
   at transmission of HEARTBEAT, and it is completed at reception of the
   corresponding SACK or HEARTBEAT ACK from the remote peer endpoint.

   The RTT measurements results, which are based on data transfer and
   SACK reception, will be influenced by the following main components:

      a)  Transport network's physical layer propagation times in
          forward and backward directions.

      b)  IP network layer IP packets' sending, receiving and processing
          times in forward and backward directions.

      c)  The time to send, receive and process SCTP packet at the
          transmitting and receiving SCTP endpoints.




Jovev & Proshin         Expires November 10, 2019              [Page 10]

Internet-Draft                                                  May 2019


      d)  SACK sending delay when SACK is not sent for every received
          packet.

   A similar RTT structuring can be constructed for the RTT measurements
   based on HEARTBEAT and HEARTBEAT ACK however, since HEARTBEAT ACK is
   sent for every HEARTBEAT with no delay, the HEARTBEAT based RTT
   estimation is less 'challenging' and it will not be examined in
   detail in this document.

   The component 'a)', the transport network's physical layer
   propagation time is a stable component determined primarily by the
   length of the connection between two endpoints and to a very small
   degree by the nature of the physical medium (coper, coax cable, radio
   link, etc.).  This component determines the theoretical/absolute
   minimum RTT time and it changes only when the physical properties of
   the connection, primarily the length, are changed.

   The components 'b)' and 'c)', the IP network layer and SCTP endpoints
   packets sending, receiving and processing times are proportional to
   the traffic level (A) by factor 1/(1-A), which is the mean value of
   the waiting queues length.  However, the actual time durations are
   derived as a product of the waiting queue length (the number of
   packets waiting to be processed) and the time to process a packet
   (the time to transmit/receive packet or the time to process a packet
   by the protocol stack's layers).  Since the waiting queues' lengths
   are variable the aggregated time to send, receive and process SCTP
   packet will be variable too.  Because the networks' load variation's
   gradient is generally small and because the telecom networks'
   signalling traffic is normally carried over high speed IP backbone
   networks with engineered capacity i.e., with no congestion, the
   variation of this timing components values will be significantly
   smaller than the variation range due to SACK delay.

   The time component due to bullet 'd)' is the delay time inserted by
   the SCTP protocol rules and it is applicable only when the SACK is
   not returned on every packet.

   Namely, when SACK is returned on every received packet, the RTT
   measurement value R is determined only by the combined time from
   components 'a)', 'b)' and 'c)', which in this context will be called
   NRTT (Network RTT).  However, when the SACK is not returned on every
   packet i.e., when the SACK is returned on every 'N-th' received
   packet, and N > 1, the RTT measurement value R is determined by NRTT
   and the allowed SACK delay time.

   Specifically, if the packets' arrival rate/frequency F is low,
   relative to the value of the protocol parameter SACK delay timer
   (SACK.Delay.timer), i.e., if the relation



Jovev & Proshin         Expires November 10, 2019              [Page 11]

Internet-Draft                                                  May 2019


      (N - 1) * 1/F >= SACK.Delay.timer

   is true, the RTT measurement value will be determined by the NRTT and
   the SACK.Delay.  In that case, the RTT measurement value R can be
   expressed as follows:

      R = NRTT + SACK.Delay.timer.

   Alternatively, if the packets' arrival rate F is high, relative to
   the SACK.Delay, i.e., if the inequation

      (N - 1) * 1/F < SACK.Delay.timer

   is true, the RTT measurement value will be determined by the NRTT and
   the time to receive the number of packets required to trigger sending
   of SACK.  In that case, the RTT measurement value can be expressed as
   follows:

      R = NRTT + (N - 1) * 1/F.

   Since by the [RFC4960] specifications the number of received packets
   that is required to trigger sending of SACK is limited to 2 (N = 2),
   the expression for the RTT measurement value can be simplified as
   follows:

      R = NRTT + 1/F.

   Thus, in general, the RTT measurement value can be expressed as
   follows:

      R = NRTT + min(SACK.Delay.timer, 1/F).

   In other words, for any packet arrival rate F, the shortest RTT
   measurement value is greater than the NRTT and the longest RTT
   measurement value does not exceed NRTT plus SACK.Delay i.e., the
   following relation is true:

      NRTT + 1/maxF < R <= NRTT + SACK.Delay.timer,

   where maxF is the highest packets arrival rate.  Consequently, the
   range of the RTT measurements R is given by the following relation:

      NRTT + 1/maxF <= R <= NRTT + SACK.Delay.timer,

   Or in other words, the values of the RTT measurements R will be
   between a minimum value (minR) that is determined as:

      minR = NRTT + 1/maxF,



Jovev & Proshin         Expires November 10, 2019              [Page 12]

Internet-Draft                                                  May 2019


   and a maximum value (maxR) that is determined as:

      maxR = NRTT + SACK.Delay.timer.

   The above presented RTT related relations are illustrated in
   Figure 3.

                           R values
                             range
                          /--------\
                NRTT    minR      maxR
   |--------------#------#---------#-------->
   0              \------/                   R
                   1/maxF
                  \----------------/
                   SACK.Delay.timer

       Figure 3: The expected values range of the RTT measurements R

   The above analysis also shows that the SACK delay, in practical
   terms, significantly increases the RTT (R'), which leads to
   conclusion that the calculated SRTT (mean RTT) by formula:

      SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R';

   converges to a value greater than NRTT + 1/maxF i.e., to a value
   greater than the lowest RTT, regardless of the variation pattern of
   the measured RTTs.

   At that same time, the above analysis shows that the SACK delay
   significantly increases the RTT measurement (R') variation range but
   it does not alter the RTTVAR convergence to 0, or rather low values
   when calculated by formula:

      RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|.

   Or in other words, the RTTVAR calculation can still yield low values
   even though the SACK delay increases the RTT measurement (R')
   variation range (refer to Figure 3).

   That, combined with the fact that RTTVAR contribution to the RTO
   value is 4 times of SRTT (RTO <- SRTT + 4 * RTTVAR), leads to
   conclusion that the RTO underestimations are primarily due to low
   RTTVAR values.  Thus, instead of setting low threshold for the
   calculated RTO, which is the role of rule C6, the compensation for
   underestimated RTOs should be achieved by setting low threshold for
   RTTVAR as follows:




Jovev & Proshin         Expires November 10, 2019              [Page 13]

Internet-Draft                                                  May 2019


      After calculating RTTVAR by formula:

      RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|,

      if RTTVAR is less than RTTVAR.Min set RTTVAR to RTTVAR.Min.

   Or by altering the RTO calculation formula as follows:

      RTO <- SRTT + max(4 * RTTVAR, RTTVAR.Min).

   However, to avoid introduction of new protocol parameter, and because
   the existing RTO.Min protocol parameter is no longer used, RTO.Min
   can take the role of the RTTVAR.Min.  In that case, the RTO
   calculation formula will be expressed as follows:

      RTO <- SRTT + max(4 * RTTVAR, RTO.Min).

   The above formula ensures that, in case of low RTTVAR values, the RTO
   margin to absorb unexpected SACK delays is determined by the RTO.Min
   (the RTTVAR.Min alias) only, thus, it is constant and independent of
   the SRTT (refer to the illustration in Figure 4).





       RTO margin
            ^
            |
   RTO.Min  +--------------------------
            |
            |
            |
            |
            |
            |
            |
            +-------------------------->
            0                         SRTT

    Figure 4: Relation between the RTO margin and SRTT with the new RTO
                             calculation rules

   Since the RTT variation range introduced by SACK delay is predictable
   i.e., the RTT variation range introduced by SACK delay is, in
   practical terms, determined by the SACK delay time (refer to
   Figure 2), the value of the RTTVAR low threshold should be determined
   based on the SACK delay time used at the remote peer.



Jovev & Proshin         Expires November 10, 2019              [Page 14]

Internet-Draft                                                  May 2019


   The [RFC4960] recommended value for RTO.Min does not require change
   when the RTO.Min is used as RTTVAR low threshold in the above
   modified formula for RTO calculation.  Namely, the recommended 1 sec
   correspond to 2 times the allowed SACK delay time, which is 500 msec.

Authors' Addresses

   Dimitar Jovev
   Ericsson

   Email: dimitar.jovev@gmail.com


   Maksim Proshin
   Ericsson
   Kistavaegen 25
   Stockholm  164 80
   Sweden

   Email: mproshin@tieto.mera.ru































Jovev & Proshin         Expires November 10, 2019              [Page 15]