idnits 2.17.1 draft-jovev-tsvwg-sctp-rto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2017) is 2340 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Jovev 3 Internet-Draft M. Proshin 4 Intended status: Standards Track Ericsson 5 Expires: May 27, 2018 November 23, 2017 7 Determining SCTP's Retransmission Timer 8 draft-jovev-tsvwg-sctp-rto-01 10 Abstract 12 This document defines a modification in the RFC 4960 [RFC4960] 13 defined Stream Control Transmission Protocol's (SCTP's) 14 Retransmission Timer (RTO) calculation method. 16 The modification is aimed to reduce the frequency of spurious T3 17 timeouts, which are caused by underestimated RTO values, derived by 18 the [RFC4960] defend RTO calculation method. The proposed 19 modification aligns the RTO calculation method with the 20 characteristics of the statistical estimator algorithms, which are 21 used for SRTT and RTTVAR calculation, the SCTP protocol data transfer 22 rules and the characteristics of the data packets' arrival pattern in 23 the telecom signalling networks. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 27, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 61 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 62 3. The modified algorithm for RTO Calculation . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 6.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Appendix A. Technical background for the modifications in the 69 RTO calculation algorithm . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 Like TCP, the SCTP's reliable transfer of data is ensured by limiting 75 the time in which the acknowledgement for the reception of the 76 transmitted data is received, after which expiration all 77 unacknowledged data is retransmitted. The duration of this timer is 78 referred to as Retransmission Timeout (RTO) and the actual timer is 79 called T3-rtx or just T3. 81 The expiration of the T3 timer not only invokes retransmission of the 82 unacknowledged data it also drastically reduces the congestion window 83 (cwnd) to 1 MTU, which are both undesirable actions: data 84 retransmission increases the amount of sent data in the network, and 85 1 MTU cwnd drastically reduces the SCTP association transmission 86 capacity. Because of that, determining an RTO value which reflects 87 the highest RTT, or the highest feedback time, as more appropriately 88 called in [ALLMAN99], is critical for reducing the probability of 89 spurious T3 timeouts, which is critically important for stable SCTP 90 operation. 92 Namely, while in the conventional file transfer applications the 93 transport layer transmission capacity reduction, due to T3 timeouts, 94 only prolongs the time for completion of the file transfer, in the 95 telecom signalling networks it often results in false congestion 96 i.e., congestion caused by SCTP transmission capacity reduction not 97 by traffic increase, which can lead to unrepairable loss of data that 98 adversely affects the services provided by the telecom networks. 100 This document defines a modification in the [RFC4960] defined SCTP's 101 Retransmission Timer (RTO) calculation method. The modification is 102 aimed to reduce the frequency of spurious T3 timeouts, which are 103 caused by underestimated RTO values, by adjusting the RTO calculation 104 method to the characteristics of the statistical estimator 105 algorithms, which are used for SRTT and RTTVAR calculation, and to 106 the SCTP protocol data transfer rules and the characteristics of the 107 data packets' arrival pattern in the telecom signalling networks. 109 The modified RTO calculation affects only the sender side and it does 110 not require introduction of new protocol variables or parameters nor 111 change of the [RFC4960] recommended values for the existing RTO 112 related protocol parameters. 114 The motivations for the modification in the [RFC4960] algorithm for 115 RTO calculation are outlined in Section 2. The actual modification 116 in the [RFC4960] algorithm for RTO calculation is specified in 117 Section 3 whereas the technical background for the modification is 118 elaborated in the Appendix A. 120 1.1. Conventions and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Problem description 128 The [RFC4960] defined process for RTO determination consists of two 129 steps. 131 In the first step, using RTT measurements as input data, a calculated 132 RTO value is derived from the mean/smooth RTT (SRTT) and RTT 133 variation (RTTVAR) values, which are determined using a statistical 134 estimator algorithm, originally published in [JAC88], and then, in 135 the second step, the used RTO is determined as: 137 RTO <- min(RTO.Max, max(calculated RTO, RTO.Min)), 139 where RTO.Min and RTO.Max are configurable protocol parameters with 140 [RFC4960] recommended values of 1 sec and 60 seconds. 142 By applying the [RFC4960] RTO calculation rules, the RTO value that 143 will be used for the T3 timer will be: 145 * The value of the RTO.Min - if the calculated RTO is below 146 RTO.Min. 148 * The calculated RTO - if the calculated RTO is above RTO.Min but 149 below RTO.Max. 151 * The value of the RTO.Max - if the calculated RTO is above 152 RTO.Max. 154 Diagram in Figure 1 illustrates the outcome of the above RTO 155 determination rules. 157 Used RTO 158 ^ 159 | 160 RTO.MAX +. . . . . .+----------------- 161 | / . 162 | / . 163 | / . 164 | / . 165 | / . 166 RTO.Min +-----+ . 167 | . . 168 | . . 169 | . . 170 | . . 171 +-----+------+---------------> 172 Calculated RTO 173 RTO.Min RTO.Max 175 Figure 1: Relation between the calculated and used RTO values 177 The SCTP protocol has been operating in the telecom networks for more 178 than fifteen years and spurious T3 timeouts have been one of the most 179 frequently reported problems. 181 The results of the analysis of the spurious T3 timeouts problems, 182 reported from the operating networks, indicated that the spurious T3 183 timeouts frequency increases when the SRTT value is closer to the 184 RTO.Min value to the point where the association becomes unstable if 185 the SRTT is longer than the RTO.Min value. The analysis of these 186 problems also showed that the reported spurious T3 timeouts problems 187 were resolved only by increasing the RTO.Min value well above the 188 SRTT value. 190 The fact that the spurious T3 timeouts were successfully prevented 191 only by setting the RTO.Min value considerably above the SRTT value, 192 leads to conclusion that the RTO values, which are derived by the 194 [RFC4960] defend rules, are inadequate for the RTT variation pattern 195 in the telecom signalling networks. 197 In other words, the fact that the SCTP association operation is 198 stable only when the RTO.Min value is well above the SRTT value, 199 makes the RTO calculation, which is specified by the [RFC4960] 200 section 6.3.1. rules C1 C2 and C3, seemingly redundant. 202 To help visualise the problem, let assume, hypothetically, that the 203 packets transmission pattern consists of high packet rate sequences 204 longer than 500 msec with, for example, 200 packets/sec, which 205 separated by 50 to 80 ms "idle" gaps. For such packet rate pattern, 206 the statistical estimator algorithm for RTTVAR will produce a very 207 low RTTVAR values, very likely well below 5 msec, because, during the 208 long high packet rate sequences, the SACK delay will vary around 5 209 msec due to packet rate of 200 packets/sec. 211 Consequently, with the [RFC4960] RTO calculation rule: 213 RTO <- max(SRTT + 4 * RTTVAR, RTO.Min), 215 the RTO margin to absorb unexpected SACK delays, in this hypothetical 216 case 50 to 80 msec due to the packet transmission gaps, is determined 217 by the difference between the calculated RTO value and the measured 218 (calculated) SRTT. 220 Since in case of low RTTVAR values the RTO is determined by the 221 RTO.Min parameter, the RTO margin will be equal to the difference 222 between the RTO.Min and SRTT (RTO margin = RTO.Min - SRTT). Thus, as 223 illustrated in Figure 2, the [RFC4960] RTO calculation rules produce 224 robust RTO values only when the SRTT is well below RTO.Min parameter 225 value, which is the root cause of the problem. 227 RTO margin 228 ^ 229 | 230 RTO.Min + 231 | \ 232 | \ 233 | \ 234 | \ 235 | \ 236 | \ 237 | \ 238 +---------------+----------> 239 0 SRTT 240 RTO.Min 242 Figure 2: Relation between the RTO margin and SRTT 244 To rectify this anomaly, this document introduces modification in the 245 [RFC4960] algorithm for RTO calculation. The actual modification is 246 specified in Section 3 and it includes only change in the use of the 247 RTO.Min protocol parameter; the technical background for the 248 modification is elaborated in the Appendix A. 250 3. The modified algorithm for RTO Calculation 252 The modified rules governing the computation of SRTT, RTTVAR and RTO 253 are as follows: 255 C1) Until an RTT measurement has been made for a packet sent to 256 the given destination transport address, set RTO to the 257 protocol parameter 'RTO.Initial'. 259 C2) When the first RTT measurement R is made, set 261 SRTT <- R, 263 RTTVAR <- R/2, and 265 RTO <- SRTT + max(4 * RTTVAR, RTO.Min). 267 C3) When a new RTT measurement R' is made, set 269 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| 271 and 273 SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' 274 Note: The value of SRTT used in the update to RTTVAR is its 275 value before updating SRTT itself using the second 276 assignment. 278 After the SRTT and RTTVAR computation, update RTO: 280 RTO <- SRTT + max(4 * RTTVAR, RTO.Min). 282 C4) When data is in flight and when allowed by rule C5 below, a 283 new RTT measurement MUST be made each round trip. 284 Furthermore, new RTT measurements SHOULD be made no more than 285 once per round trip for a given destination transport 286 address. There are two reasons for this recommendation: 287 First, it appears that measuring more frequently often does 288 not in practice yield any significant benefit [ALLMAN99]; 289 second, if measurements are made more often, then the values 290 of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted 291 so that SRTT and RTTVAR still adjust to changes at roughly 292 the same rate (in terms of how many round trips it takes them 293 to reflect new values) as they would if making only one 294 measurement per round-trip and using RTO.Alpha and RTO.Beta 295 as given in rule C3. However, the exact nature of these 296 adjustments remains a research issue. 298 C5) Karn's algorithm: RTT measurements MUST NOT be made using 299 packets that were retransmitted (and thus for which it is 300 ambiguous whether the reply was for the first instance of the 301 chunk or for a later instance). 303 IMPLEMENTATION NOTE: RTT measurements should only be made 304 using a chunk with TSN r if no chunk with TSN less than or 305 equal to r is retransmitted since r is first sent. 307 C6) A maximum value may be placed on RTO provided it is at least 308 RTO.max seconds. 310 There is no requirement for the clock granularity G used for 311 computing RTT measurements and the different state variables, other 312 than: 314 G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- 315 G. 317 Experience [ALLMAN99] has shown that finer clock granularities (<= 318 100 msec) perform somewhat better than more coarse granularities. 320 4. IANA Considerations 322 This document does not create any new registries or modify the rules 323 for any existing registries managed by IANA. 325 5. Security Considerations 327 This document does not add any security considerations to those given 328 in [RFC4960]. 330 6. References 332 6.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 340 September 2007, . 342 6.2. Informative References 344 [ALLMAN99] 345 Mark Allman and Vern Paxson, "On Estimating End-to-End 346 Network Path Properties", 1999, 347 . 350 [JAC88] Van Jacobson and Michael J. Karels , "Congestion Avoidance 351 and Control", November 1988, 352 . 355 Appendix A. Technical background for the modifications in the RTO 356 calculation algorithm 358 As indicated in Section 2, with the [RFC4960] RTO calculation rules, 359 the frequency of spurious T3 timeouts increases when the SRTT value 360 is close to the RTO.Min value to the point where, under heavy load, 361 the association becomes unstable if the SRTT is longer than the 362 RTO.Min value. 364 The reasons for such outcome can be contributed to the following 365 factors: 367 a) The characteristic of the statistical estimator algorithms for 368 SRTT and RTTVAR calculation; 370 b) The anomalies in the distribution of the RTT measurement 371 values caused by the [RFC4960] SACK generation rules, 372 specifically, the delay of SACK sending; and 374 c) Inappropriate solution for protection against underestimated 375 RTO values. 377 The characteristics of the statistical estimator algorithms for SRTT 378 and RTTVAR, which are the foundation for RTO calculation, are well 379 known and widely investigated in terms of improving the outcome 380 (reduction of spurious T3 timeouts) by adjustment of the statistical 381 estimator algorithms' configurable parameters. For example, the 382 investigation results published in [ALLMAN99] indicate that lower 383 gain factors RTO.Alpha and RTO.Beta, in the SRTT and RTTVAR 384 calculations formulas, reduces the probability of computing a low RTO 385 value that will result in T3 timeout. The same source also states 386 that lower spurious T3 timeouts probability is also achieved by 387 increasing the RTTVAR component i.e., the value of the factor K in 388 the RTO calculation formula: 390 RTO <- SRTT + K * RTTVAR. 392 This behaviour can be related to the well-known characteristic of the 393 statistical estimator algorithms for SRTT and RTTVAR estimation, 394 which can be described as follows: If the RTT measurements values 395 converge to a single RTT value, the calculated RTTVAR converge to 396 zero (0) and the calculated RTO converge to SRTT. As a result, a 397 relatively short sequence of moderately low RTT values, which are 398 within the RTT values range, simultaneously lowers the SRTT and 399 RTTVAR values to the point where the calculated RTO value is below 400 the highest value in the RTT variation range, which may result in 401 spurious T3 timeout if the next RTT is at the top of the RTT 402 variation range. 404 This 'problem' is further exacerbated by the SCTP protocol rules for 405 sending SACK which allow SACK delay of up to 500 msec. Namely, the 406 SACK delay rules, combined with burst nature of the data packets' 407 arrival pattern in the telecom signalling networks, drastically 408 increase the jitteriness of the RTT measurements. That, in turn, 409 adversely affect the results obtained by statistical estimator 410 algorithms for SRTT and RTTVAR calculations in terms of 411 underestimated RTO values that are prone to spurious T3 timeouts. 413 Obviously, and as proven in the operating networks, an RTO determined 414 by application of rule C6, with an RTO.Min value in seconds, 415 practically eliminates underestimated RTO values and with that the 416 spurious T3 timeouts. That is because the 1 second RTO will be well 417 above the delay inserted by the terrestrial transport networks, which 418 operate with latency below 100 msec, and because the SACK delay is 419 also well below 1 second. 421 However, an RTO value in seconds, coupled with the RTO back-off rule 422 RTO <- RTO * 2, results in too long detection of remote endpoint 423 failure or complete failure of the physical layer. For example, with 424 the [RFC4960] recommended RTO.Min of 1 second, RTO.Max of 60 seconds 425 and Association.Max.Retrans of 4 attempts, the association closure 426 time will be 31 seconds, which is an unacceptably long time that, 427 under high load, can potentially destabilise the operation of the 428 network. 430 Namely, in the telecom networks where the client nodes are connected 431 to redundant server nodes and where multiple load sharing SCTP 432 associations are used between the nodes, a timely detection of the 433 SCTP remote peer endpoint failure, or complete failure of the 434 physical layer, is critical to enables failover to the redundant 435 resources. 437 Thus, instead of using an arbitrary long RTO defend by RTO.Min 438 parameter, which practically makes the calculated RTO value by rules 439 C1, C2 and C3 redundant, the RTO value should reflect, as close as 440 possible, the real conditions in the network in terms of the time to 441 transport the packets between two endpoints, the time delays induced 442 by the SCTP protocol rules and to also include adequate additional 443 time as protection against underestimated RTO values. To achieve 444 that, the subsequent paragraphs first analyse the characteristics of 445 the RTT components and then specify a modified RTO calculation 446 algorithm which is derived from the characteristics of the 447 statistical estimator algorithms for SRTT and RTTVAR and the 448 characteristics of the RTT components. 450 Specifically, an RTT measurement starts at transmission of data, or 451 at transmission of HEARTBEAT, and it is completed at reception of the 452 corresponding SACK or HEARTBEAT ACK from the remote peer endpoint. 454 The RTT measurements results, which are based on data transfer and 455 SACK reception, will be influenced by the following main components: 457 a) Transport network's physical layer propagation times in 458 forward and backward directions. 460 b) IP network layer IP packets' sending, receiving and processing 461 times in forward and backward directions. 463 c) The time to send, receive and process SCTP packet at the 464 transmitting and receiving SCTP endpoints. 466 d) SACK sending delay when SACK is not sent for every received 467 packet. 469 A similar RTT structuring can be constructed for the RTT measurements 470 based on HEARTBEAT and HEARTBEAT ACK however, since HEARTBEAT ACK is 471 sent for every HEARTBEAT with no delay, the HEARTBEAT based RTT 472 estimation is less 'challenging' and it will not be examined in 473 detail in this document. 475 The component 'a)', the transport network's physical layer 476 propagation time is a stable component determined primarily by the 477 length of the connection between two endpoints and to a very small 478 degree by the nature of the physical medium (coper, coax cable, radio 479 link, etc.). This component determines the theoretical/absolute 480 minimum RTT time and it changes only when the physical properties of 481 the connection, primarily the length, are changed. 483 The components 'b)' and 'c)', the IP network layer and SCTP endpoints 484 packets sending, receiving and processing times are proportional to 485 the traffic level (A) by factor 1/(1-A), which is the mean value of 486 the waiting queues length. However, the actual time durations are 487 derived as a product of the waiting queue length (the number of 488 packets waiting to be processed) and the time to process a packet 489 (the time to transmit/receive packet or the time to process a packet 490 by the protocol stack's layers). Since the waiting queues' lengths 491 are variable the aggregated time to send, receive and process SCTP 492 packet will be variable too. Because the networks' load variation's 493 gradient is generally small and because the telecom networks' 494 signalling traffic is normally carried over high speed IP backbone 495 networks with engineered capacity i.e., with no congestion, the 496 variation of this timing components values will be significantly 497 smaller than the variation range due to SACK delay. 499 The time component due to bullet 'd)' is the delay time inserted by 500 the SCTP protocol rules and it is applicable only when the SACK is 501 not returned on every packet. 503 Namely, when SACK is returned on every received packet, the RTT 504 measurement value R is determined only by the combined time from 505 components 'a)', 'b)' and 'c)', which in this context will be called 506 NRTT (Network RTT). However, when the SACK is not returned on every 507 packet i.e., when the SACK is returned on every 'N-th' received 508 packet, and N > 1, the RTT measurement value R is determined by NRTT 509 and the allowed SACK delay time. 511 Specifically, if the packets' arrival rate/frequency F is low, 512 relative to the value of the protocol parameter SACK delay timer 513 (SACK.Delay.timer), i.e., if the relation 515 (N - 1) * 1/F >= SACK.Delay.timer 517 is true, the RTT measurement value will be determined by the NRTT and 518 the SACK.Delay. In that case, the RTT measurement value R can be 519 expressed as follows: 521 R = NRTT + SACK.Delay.timer. 523 Alternatively, if the packets' arrival rate F is high, relative to 524 the SACK.Delay, i.e., if the inequation 526 (N - 1) * 1/F < SACK.Delay.timer 528 is true, the RTT measurement value will be determined by the NRTT and 529 the time to receive the number of packets required to trigger sending 530 of SACK. In that case, the RTT measurement value can be expressed as 531 follows: 533 R = NRTT + (N - 1) * 1/F. 535 Since by the [RFC4960] specifications the number of received packets 536 that is required to trigger sending of SACK is limited to 2 (N = 2), 537 the expression for the RTT measurement value can be simplified as 538 follows: 540 R = NRTT + 1/F. 542 Thus, in general, the RTT measurement value can be expressed as 543 follows: 545 R = NRTT + min(SACK.Delay.timer, 1/F). 547 In other words, for any packet arrival rate F, the shortest RTT 548 measurement value is greater than the NRTT and the longest RTT 549 measurement value does not exceed NRTT plus SACK.Delay i.e., the 550 following relation is true: 552 NRTT + 1/maxF < R <= NRTT + SACK.Delay.timer, 554 where maxF is the highest packets arrival rate. Consequently, the 555 range of the RTT measurements R is given by the following relation: 557 NRTT + 1/maxF <= R <= NRTT + SACK.Delay.timer, 559 Or in other words, the values of the RTT measurements R will be 560 between a minimum value (minR) that is determined as: 562 minR = NRTT + 1/maxF, 564 and a maximum value (maxR) that is determined as: 566 maxR = NRTT + SACK.Delay.timer. 568 The above presented RTT related relations are illustrated in 569 Figure 3. 571 R values 572 range 573 /--------\ 574 NRTT minR maxR 575 |--------------#------#---------#--------> 576 0 \------/ R 577 1/maxF 578 \----------------/ 579 SACK.Delay.timer 581 Figure 3: The expected values range of the RTT measurements R 583 The above analysis also shows that the SACK delay, in practical 584 terms, significantly increases the RTT (R'), which leads to 585 conclusion that the calculated SRTT (mean RTT) by formula: 587 SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'; 589 converges to a value greater than NRTT + 1/maxF i.e., to a value 590 greater than the lowest RTT, regardless of the variation pattern of 591 the measured RTTs. 593 At that same time, the above analysis shows that the SACK delay 594 significantly increases the RTT measurement (R') variation range but 595 it does not alter the RTTVAR convergence to 0, or rather low values 596 when calculated by formula: 598 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|. 600 Or in other words, the RTTVAR calculation can still yield low values 601 even though the SACK delay increases the RTT measurement (R') 602 variation range (refer to Figure 3). 604 That, combined with the fact that RTTVAR contribution to the RTO 605 value is 4 times of SRTT (RTO <- SRTT + 4 * RTTVAR), leads to 606 conclusion that the RTO underestimations are primarily due to low 607 RTTVAR values. Thus, instead of setting low threshold for the 608 calculated RTO, which is the role of rule C6, the compensation for 609 underestimated RTOs should be achieved by setting low threshold for 610 RTTVAR as follows: 612 After calculating RTTVAR by formula: 614 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|, 616 if RTTVAR is less than RTTVAR.Min set RTTVAR to RTTVAR.Min. 618 Or by altering the RTO calculation formula as follows: 620 RTO <- SRTT + max(4 * RTTVAR, RTTVAR.Min). 622 However, to avoid introduction of new protocol parameter, and because 623 the existing RTO.Min protocol parameter is no longer used, RTO.Min 624 can take the role of the RTTVAR.Min. In that case, the RTO 625 calculation formula will be expressed as follows: 627 RTO <- SRTT + max(4 * RTTVAR, RTO.Min). 629 The above formula ensures that, in case of low RTTVAR values, the RTO 630 margin to absorb unexpected SACK delays is determined by the RTO.Min 631 (the RTTVAR.Min alias) only, thus, it is constant and independent of 632 the SRTT (refer to the illustration in Figure 4). 634 RTO margin 635 ^ 636 | 637 RTO.Min +-------------------------- 638 | 639 | 640 | 641 | 642 | 643 | 644 | 645 +--------------------------> 646 0 SRTT 648 Figure 4: Relation between the RTO margin and SRTT with the new RTO 649 calculation rules 651 Since the RTT variation range introduced by SACK delay is predictable 652 i.e., the RTT variation range introduced by SACK delay is, in 653 practical terms, determined by the SACK delay time (refer to 654 Figure 2), the value of the RTTVAR low threshold should be determined 655 based on the SACK delay time used at the remote peer. 657 The [RFC4960] recommended value for RTO.Min does not require change 658 when the RTO.Min is used as RTTVAR low threshold in the above 659 modified formula for RTO calculation. Namely, the recommended 1 sec 660 correspond to 2 times the allowed SACK delay time, which is 500 msec. 662 Authors' Addresses 664 Dimitar Jovev 665 Ericsson 666 818 Bourke St. 667 Melbourne, Victoria 3008 668 Australia 670 Email: dimitar.jovev@gmail.com 672 Maksim Proshin 673 Ericsson 674 Kistavaegen 25 675 Stockholm 164 80 676 Sweden 678 Email: mproshin@tieto.mera.ru