idnits 2.16.02
/tmp/draft-jovev-tsvwg-sctp-rto-04.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 document date (May 9, 2019) is 39 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)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 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: November 10, 2019 May 9, 2019
7 Determining SCTP's Retransmission Timer
8 draft-jovev-tsvwg-sctp-rto-04
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 November 10, 2019.
42 Copyright Notice
44 Copyright (c) 2019 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 and SIGCOMM'99, "On Estimating End-to-End Network Path
346 Properties", 1999, .
349 [JAC88] and , "Congestion Avoidance and Control", November 1988,
350 .
353 Appendix A. Technical background for the modifications in the RTO
354 calculation algorithm
356 As indicated in Section 2, with the [RFC4960] RTO calculation rules,
357 the frequency of spurious T3 timeouts increases when the SRTT value
358 is close to the RTO.Min value to the point where, under heavy load,
359 the association becomes unstable if the SRTT is longer than the
360 RTO.Min value.
362 The reasons for such outcome can be contributed to the following
363 factors:
365 a) The characteristic of the statistical estimator algorithms for
366 SRTT and RTTVAR calculation;
368 b) The anomalies in the distribution of the RTT measurement
369 values caused by the [RFC4960] SACK generation rules,
370 specifically, the delay of SACK sending; and
372 c) Inappropriate solution for protection against underestimated
373 RTO values.
375 The characteristics of the statistical estimator algorithms for SRTT
376 and RTTVAR, which are the foundation for RTO calculation, are well
377 known and widely investigated in terms of improving the outcome
378 (reduction of spurious T3 timeouts) by adjustment of the statistical
379 estimator algorithms' configurable parameters. For example, the
380 investigation results published in [ALLMAN99] indicate that lower
381 gain factors RTO.Alpha and RTO.Beta, in the SRTT and RTTVAR
382 calculations formulas, reduces the probability of computing a low RTO
383 value that will result in T3 timeout. The same source also states
384 that lower spurious T3 timeouts probability is also achieved by
385 increasing the RTTVAR component i.e., the value of the factor K in
386 the RTO calculation formula:
388 RTO <- SRTT + K * RTTVAR.
390 This behaviour can be related to the well-known characteristic of the
391 statistical estimator algorithms for SRTT and RTTVAR estimation,
392 which can be described as follows: If the RTT measurements values
393 converge to a single RTT value, the calculated RTTVAR converge to
394 zero (0) and the calculated RTO converge to SRTT. As a result, a
395 relatively short sequence of moderately low RTT values, which are
396 within the RTT values range, simultaneously lowers the SRTT and
397 RTTVAR values to the point where the calculated RTO value is below
398 the highest value in the RTT variation range, which may result in
399 spurious T3 timeout if the next RTT is at the top of the RTT
400 variation range.
402 This 'problem' is further exacerbated by the SCTP protocol rules for
403 sending SACK which allow SACK delay of up to 500 msec. Namely, the
404 SACK delay rules, combined with burst nature of the data packets'
405 arrival pattern in the telecom signalling networks, drastically
406 increase the jitteriness of the RTT measurements. That, in turn,
407 adversely affect the results obtained by statistical estimator
408 algorithms for SRTT and RTTVAR calculations in terms of
409 underestimated RTO values that are prone to spurious T3 timeouts.
411 Obviously, and as proven in the operating networks, an RTO determined
412 by application of rule C6, with an RTO.Min value in seconds,
413 practically eliminates underestimated RTO values and with that the
414 spurious T3 timeouts. That is because the 1 second RTO will be well
415 above the delay inserted by the terrestrial transport networks, which
416 operate with latency below 100 msec, and because the SACK delay is
417 also well below 1 second.
419 However, an RTO value in seconds, coupled with the RTO back-off rule
420 RTO <- RTO * 2, results in too long detection of remote endpoint
421 failure or complete failure of the physical layer. For example, with
422 the [RFC4960] recommended RTO.Min of 1 second, RTO.Max of 60 seconds
423 and Association.Max.Retrans of 4 attempts, the association closure
424 time will be 31 seconds, which is an unacceptably long time that,
425 under high load, can potentially destabilise the operation of the
426 network.
428 Namely, in the telecom networks where the client nodes are connected
429 to redundant server nodes and where multiple load sharing SCTP
430 associations are used between the nodes, a timely detection of the
431 SCTP remote peer endpoint failure, or complete failure of the
432 physical layer, is critical to enables failover to the redundant
433 resources.
435 Thus, instead of using an arbitrary long RTO defend by RTO.Min
436 parameter, which practically makes the calculated RTO value by rules
437 C1, C2 and C3 redundant, the RTO value should reflect, as close as
438 possible, the real conditions in the network in terms of the time to
439 transport the packets between two endpoints, the time delays induced
440 by the SCTP protocol rules and to also include adequate additional
441 time as protection against underestimated RTO values. To achieve
442 that, the subsequent paragraphs first analyse the characteristics of
443 the RTT components and then specify a modified RTO calculation
444 algorithm which is derived from the characteristics of the
445 statistical estimator algorithms for SRTT and RTTVAR and the
446 characteristics of the RTT components.
448 Specifically, an RTT measurement starts at transmission of data, or
449 at transmission of HEARTBEAT, and it is completed at reception of the
450 corresponding SACK or HEARTBEAT ACK from the remote peer endpoint.
452 The RTT measurements results, which are based on data transfer and
453 SACK reception, will be influenced by the following main components:
455 a) Transport network's physical layer propagation times in
456 forward and backward directions.
458 b) IP network layer IP packets' sending, receiving and processing
459 times in forward and backward directions.
461 c) The time to send, receive and process SCTP packet at the
462 transmitting and receiving SCTP endpoints.
464 d) SACK sending delay when SACK is not sent for every received
465 packet.
467 A similar RTT structuring can be constructed for the RTT measurements
468 based on HEARTBEAT and HEARTBEAT ACK however, since HEARTBEAT ACK is
469 sent for every HEARTBEAT with no delay, the HEARTBEAT based RTT
470 estimation is less 'challenging' and it will not be examined in
471 detail in this document.
473 The component 'a)', the transport network's physical layer
474 propagation time is a stable component determined primarily by the
475 length of the connection between two endpoints and to a very small
476 degree by the nature of the physical medium (coper, coax cable, radio
477 link, etc.). This component determines the theoretical/absolute
478 minimum RTT time and it changes only when the physical properties of
479 the connection, primarily the length, are changed.
481 The components 'b)' and 'c)', the IP network layer and SCTP endpoints
482 packets sending, receiving and processing times are proportional to
483 the traffic level (A) by factor 1/(1-A), which is the mean value of
484 the waiting queues length. However, the actual time durations are
485 derived as a product of the waiting queue length (the number of
486 packets waiting to be processed) and the time to process a packet
487 (the time to transmit/receive packet or the time to process a packet
488 by the protocol stack's layers). Since the waiting queues' lengths
489 are variable the aggregated time to send, receive and process SCTP
490 packet will be variable too. Because the networks' load variation's
491 gradient is generally small and because the telecom networks'
492 signalling traffic is normally carried over high speed IP backbone
493 networks with engineered capacity i.e., with no congestion, the
494 variation of this timing components values will be significantly
495 smaller than the variation range due to SACK delay.
497 The time component due to bullet 'd)' is the delay time inserted by
498 the SCTP protocol rules and it is applicable only when the SACK is
499 not returned on every packet.
501 Namely, when SACK is returned on every received packet, the RTT
502 measurement value R is determined only by the combined time from
503 components 'a)', 'b)' and 'c)', which in this context will be called
504 NRTT (Network RTT). However, when the SACK is not returned on every
505 packet i.e., when the SACK is returned on every 'N-th' received
506 packet, and N > 1, the RTT measurement value R is determined by NRTT
507 and the allowed SACK delay time.
509 Specifically, if the packets' arrival rate/frequency F is low,
510 relative to the value of the protocol parameter SACK delay timer
511 (SACK.Delay.timer), i.e., if the relation
512 (N - 1) * 1/F >= SACK.Delay.timer
514 is true, the RTT measurement value will be determined by the NRTT and
515 the SACK.Delay. In that case, the RTT measurement value R can be
516 expressed as follows:
518 R = NRTT + SACK.Delay.timer.
520 Alternatively, if the packets' arrival rate F is high, relative to
521 the SACK.Delay, i.e., if the inequation
523 (N - 1) * 1/F < SACK.Delay.timer
525 is true, the RTT measurement value will be determined by the NRTT and
526 the time to receive the number of packets required to trigger sending
527 of SACK. In that case, the RTT measurement value can be expressed as
528 follows:
530 R = NRTT + (N - 1) * 1/F.
532 Since by the [RFC4960] specifications the number of received packets
533 that is required to trigger sending of SACK is limited to 2 (N = 2),
534 the expression for the RTT measurement value can be simplified as
535 follows:
537 R = NRTT + 1/F.
539 Thus, in general, the RTT measurement value can be expressed as
540 follows:
542 R = NRTT + min(SACK.Delay.timer, 1/F).
544 In other words, for any packet arrival rate F, the shortest RTT
545 measurement value is greater than the NRTT and the longest RTT
546 measurement value does not exceed NRTT plus SACK.Delay i.e., the
547 following relation is true:
549 NRTT + 1/maxF < R <= NRTT + SACK.Delay.timer,
551 where maxF is the highest packets arrival rate. Consequently, the
552 range of the RTT measurements R is given by the following relation:
554 NRTT + 1/maxF <= R <= NRTT + SACK.Delay.timer,
556 Or in other words, the values of the RTT measurements R will be
557 between a minimum value (minR) that is determined as:
559 minR = NRTT + 1/maxF,
561 and a maximum value (maxR) that is determined as:
563 maxR = NRTT + SACK.Delay.timer.
565 The above presented RTT related relations are illustrated in
566 Figure 3.
568 R values
569 range
570 /--------\
571 NRTT minR maxR
572 |--------------#------#---------#-------->
573 0 \------/ R
574 1/maxF
575 \----------------/
576 SACK.Delay.timer
578 Figure 3: The expected values range of the RTT measurements R
580 The above analysis also shows that the SACK delay, in practical
581 terms, significantly increases the RTT (R'), which leads to
582 conclusion that the calculated SRTT (mean RTT) by formula:
584 SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R';
586 converges to a value greater than NRTT + 1/maxF i.e., to a value
587 greater than the lowest RTT, regardless of the variation pattern of
588 the measured RTTs.
590 At that same time, the above analysis shows that the SACK delay
591 significantly increases the RTT measurement (R') variation range but
592 it does not alter the RTTVAR convergence to 0, or rather low values
593 when calculated by formula:
595 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|.
597 Or in other words, the RTTVAR calculation can still yield low values
598 even though the SACK delay increases the RTT measurement (R')
599 variation range (refer to Figure 3).
601 That, combined with the fact that RTTVAR contribution to the RTO
602 value is 4 times of SRTT (RTO <- SRTT + 4 * RTTVAR), leads to
603 conclusion that the RTO underestimations are primarily due to low
604 RTTVAR values. Thus, instead of setting low threshold for the
605 calculated RTO, which is the role of rule C6, the compensation for
606 underestimated RTOs should be achieved by setting low threshold for
607 RTTVAR as follows:
609 After calculating RTTVAR by formula:
611 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|,
613 if RTTVAR is less than RTTVAR.Min set RTTVAR to RTTVAR.Min.
615 Or by altering the RTO calculation formula as follows:
617 RTO <- SRTT + max(4 * RTTVAR, RTTVAR.Min).
619 However, to avoid introduction of new protocol parameter, and because
620 the existing RTO.Min protocol parameter is no longer used, RTO.Min
621 can take the role of the RTTVAR.Min. In that case, the RTO
622 calculation formula will be expressed as follows:
624 RTO <- SRTT + max(4 * RTTVAR, RTO.Min).
626 The above formula ensures that, in case of low RTTVAR values, the RTO
627 margin to absorb unexpected SACK delays is determined by the RTO.Min
628 (the RTTVAR.Min alias) only, thus, it is constant and independent of
629 the SRTT (refer to the illustration in Figure 4).
631 RTO margin
632 ^
633 |
634 RTO.Min +--------------------------
635 |
636 |
637 |
638 |
639 |
640 |
641 |
642 +-------------------------->
643 0 SRTT
645 Figure 4: Relation between the RTO margin and SRTT with the new RTO
646 calculation rules
648 Since the RTT variation range introduced by SACK delay is predictable
649 i.e., the RTT variation range introduced by SACK delay is, in
650 practical terms, determined by the SACK delay time (refer to
651 Figure 2), the value of the RTTVAR low threshold should be determined
652 based on the SACK delay time used at the remote peer.
654 The [RFC4960] recommended value for RTO.Min does not require change
655 when the RTO.Min is used as RTTVAR low threshold in the above
656 modified formula for RTO calculation. Namely, the recommended 1 sec
657 correspond to 2 times the allowed SACK delay time, which is 500 msec.
659 Authors' Addresses
661 Dimitar Jovev
662 Ericsson
664 Email: dimitar.jovev@gmail.com
666 Maksim Proshin
667 Ericsson
668 Kistavaegen 25
669 Stockholm 164 80
670 Sweden
672 Email: mproshin@tieto.mera.ru