idnits 2.17.1 draft-ietf-tcpm-rtorestart-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2015) is 3287 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SEG 1' is mentioned on line 172, but not defined == Missing Reference: 'SEG 2' is mentioned on line 173, but not defined == Missing Reference: 'SEG 3' is mentioned on line 178, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (tcpm) P. Hurtig 3 Internet-Draft A. Brunstrom 4 Intended status: Experimental Karlstad University 5 Expires: October 22, 2015 A. Petlund 6 Simula Research Laboratory AS 7 M. Welzl 8 University of Oslo 9 April 20, 2015 11 TCP and SCTP RTO Restart 12 draft-ietf-tcpm-rtorestart-07 14 Abstract 16 This document describes a modified sender-side algorithm for managing 17 the TCP and SCTP retransmission timers that provides faster loss 18 recovery when there is a small amount of outstanding data for a 19 connection. The modification, RTO Restart (RTOR), allows the 20 transport to restart its retransmission timer more aggressively in 21 situations where fast retransmit cannot be used. This enables faster 22 loss detection and recovery for connections that are short-lived or 23 application-limited. 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 http://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 October 22, 2015. 42 Copyright Notice 44 Copyright (c) 2015 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 (http://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 1. Introduction 59 TCP uses two mechanisms to detect segment loss. First, if a segment 60 is not acknowledged within a certain amount of time, a retransmission 61 timeout (RTO) occurs, and the segment is retransmitted [RFC6298]. 62 While the RTO is based on measured round-trip times (RTTs) between 63 the sender and receiver, it also has a conservative lower bound of 1 64 second to ensure that delayed segments are not mistaken as lost. 65 Second, when a sender receives dupACKs, the fast retransmit algorithm 66 infers segment loss and triggers a retransmission [RFC5681]. 67 Duplicate acknowledgments are generated by a receiver when out-of- 68 order segments arrive. As both segment loss and segment reordering 69 cause out-of-order arrival, fast retransmit waits for three dupACKs 70 before considering the segment as lost. In some situations, however, 71 the number of outstanding segments is not enough to trigger three 72 dupACKs, and the sender must rely on lengthy RTOs for loss recovery. 74 The number of outstanding segments can be small for several reasons: 76 (1) The connection is limited by the congestion control when the 77 path has a low total capacity (bandwidth-delay product) or the 78 connection's share of the capacity is small. It is also limited 79 by the congestion control in the first few RTTs of a connection 80 or after an RTO when the available capacity is probed using 81 slow-start. 83 (2) The connection is limited by the receiver's available buffer 84 space. 86 (3) The connection is limited by the application if the available 87 capacity of the path is not fully utilized (e.g. interactive 88 applications), or at the end of a transfer. 90 While the reasons listed above are valid for any flow, the third 91 reason is most common for applications that transmit short flows, or 92 use a bursty transmission pattern. A typical example of applications 93 that produce short flows are web-based applications. [RJ10] shows 94 that 70% of all web objects, found at the top 500 sites, are too 95 small for fast retransmit to work. [FDT13] shows that about 77% of 96 all retransmissions sent by a major web service are sent after RTO 97 expiry. Applications with bursty transmission patterns often send 98 data in response to actions, or as a reaction to real life events. 99 Typical examples of such applications are stock trading systems, 100 remote computer operations, online games, and web-based applications 101 using persistent connections. What is special about this class of 102 applications is that they often are time-dependant, and extra latency 103 can reduce the application service level [P09]. 105 The RTO Restart (RTOR) mechanism described in this document makes the 106 RTO slightly more aggressive when the number of outstanding segments 107 is too small for fast retransmit to work, in an attempt to enable 108 faster loss recovery for all segments while being robust to 109 reordering. While RTOR still conforms to the requirement in 110 [RFC6298] that segments must not be retransmitted earlier than RTO 111 seconds after their original transmission, it could increase the risk 112 of spurious timeout. Spurious timeouts can degrade the performance 113 of flows with multiple bursts of data, as a burst following a 114 spurious timeout might not fit within the reduced congestion window 115 (cwnd). There are, however, several techniques to mitigate the 116 effects of such unnecessary retransmissions (cf. [RFC4015]). To 117 determine whether this modification is safe to deploy and enable by 118 default further experimentation is required. The experiments needed 119 to determine this are discussed in Section 5 and include evaluating 120 the modification in environments with highly varying RTTs, e.g. 121 mobile networks. 123 While this document focuses on TCP, the described changes are also 124 valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] 125 which has similar loss recovery and congestion control algorithms. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 This document introduces the following variables: 135 The number of previously unsent segments (prevunsnt): The number of 136 segments that a sender has queued for transmission, but has not yet 137 sent. 139 RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of 140 the number of outstanding and previously unsent segments (prevunsnt) 141 is below this threshold. 143 3. RTO Restart Overview 145 The RTO management algorithm described in [RFC6298] recommends that 146 the retransmission timer is restarted when an acknowledgment (ACK) 147 that acknowledges new data is received and there is still outstanding 148 data. The restart is conducted to guarantee that unacknowledged 149 segments will be retransmitted after approximately RTO seconds. 150 However, by restarting the timer on each incoming ACK, 151 retransmissions are not typically triggered RTO seconds after their 152 previous transmission but rather RTO seconds after the last ACK 153 arrived. The duration of this extra delay depends on several factors 154 but is in most cases approximately one RTT. Hence, in most 155 situations, the time before a retransmission is triggered is equal to 156 "RTO + RTT". 158 The standardized RTO timer management is illustrated in Figure 1 159 where a TCP sender transmits three segments to a receiver. The 160 arrival of the first and second segment triggers a delayed ACK 161 (delACK) [RFC1122], which restarts the RTO timer at the sender. The 162 RTO is restarted approximately one RTT after the transmission of the 163 third segment. Thus, if the third segment is lost, as indicated in 164 Figure 1, the effective loss detection time is "RTO + RTT" seconds. 165 In some situations, the effective loss detection time becomes even 166 longer. Consider a scenario where only two segments are outstanding. 167 If the second segment is lost, the time to expire the delACK timer 168 will also be included in the effective loss detection time. 170 Sender Receiver 171 ... 172 DATA [SEG 1] ----------------------> (ack delayed) 173 DATA [SEG 2] ----------------------> (send ack) 174 DATA [SEG 3] ----X /-------- ACK 175 (restart RTO) <----------/ 176 ... 177 (RTO expiry) 178 DATA [SEG 3] ----------------------> 180 Figure 1: RTO restart example 182 During normal TCP bulk transfer the current RTO restart approach is 183 not a problem. Actually, as long as enough segments arrive at a 184 receiver to enable fast retransmit, RTO-based loss recovery should be 185 avoided. RTOs should only be used as a last resort, as they 186 drastically lower the congestion window compared to fast retransmit. 187 The current approach can therefore be beneficial -- it is described 188 in [EL04] to act as a "safety margin" that compensates for some of 189 the problems that the authors have identified with the standard RTO 190 calculation. Notably, the authors of [EL04] also state that "this 191 safety margin does not exist for highly interactive applications 192 where often only a single packet is in flight." 194 Although fast retransmit is preferrable there are situations where 195 timeouts are appropriate, or the only choice. For example, if the 196 network is severely congested and no segments arrive RTO-based 197 recovery should be used. In this situation, the time to recover from 198 the loss(es) will not be the performance bottleneck. However, for 199 connections that do not utilize enough capacity to enable fast 200 retransmit, RTO-based loss detection is the only choice and the time 201 required for this can become a performance bottleneck. 203 4. RTOR Algorithm 205 To enable faster loss recovery for connections that are unable to use 206 fast retransmit, RTOR can be used. This section specifies the 207 modifications required to use RTOR. By resetting the timer to "RTO - 208 T_earliest", where T_earliest is the time elapsed since the earliest 209 outstanding segment was transmitted, retransmissions will always 210 occur after exactly RTO seconds. This approach makes the RTO more 211 aggressive than the standardized approach in [RFC6298] but still 212 conforms to the requirement in [RFC6298] that segments must not be 213 retransmitted earlier than RTO seconds after their original 214 transmission. 216 This document specifies an OPTIONAL sender-only modification to TCP 217 and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a 218 similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender 219 that implements this method MUST follow the algorithm below: 221 When an ACK is received that acknowledges new data: 223 (1) Set T_earliest = 0. 225 (2) If the sum of the number of outstanding and previously unsent 226 segments (prevunsnt) is less than an RTOR threshold 227 (rrthresh), set T_earliest to the time elapsed since the 228 earliest outstanding segment was sent. 230 (3) Restart the retransmission timer so that it will expire after 231 (for the current value of RTO): 233 (a) RTO - T_earliest, if RTO - T_earliest > 0. 235 (b) RTO, otherwise. 237 The RECOMMENDED value of rrthresh is four, as it will prevent RTOR 238 from being more aggressive and potentially causing RTOs instead of 239 fast retransmits. This update needs TCP implementations to track the 240 time elapsed since the transmission of the earliest outstanding 241 segment (T_earliest). As RTOR is only used when the amount of 242 outstanding and previously unsent data is less than rrthresh 243 segments, TCP implementations also need to track whether the amount 244 of outstanding and previously unsent data is more, equal, or less 245 than rrthresh segments. Although some packet-based TCP 246 implementations (e.g. Linux TCP) already track both the transmission 247 times of all segments and also the number of outstanding segments, 248 not all implementations do. Section 5.3 describes how to implement 249 segment tracking for a general TCP implementation. To use RTOR, the 250 calculated expiration time MUST be positive (step 3(a) in the list 251 above); this is required to ensure that RTOR does not trigger 252 retransmissions prematurely when previously retransmitted segments 253 are acknowledged. 255 5. Discussion 257 In this section, we discuss the applicability and a number of issues 258 surrounding RTOR. 260 5.1. Applicability 262 The currently standardized algorithm has been shown to add at least 263 one RTT to the loss recovery process in TCP [LS00] and SCTP 264 [HB11][PBP09]. For applications that have strict timing requirements 265 (e.g. interactive web) rather than throughput requirements, using 266 RTOR could be beneficial because the RTT and also the delACK timer of 267 receivers are often large components of the effective loss recovery 268 time. Measurements in [HB11] have shown that the total transfer time 269 of a lost segment (including the original transmission time and the 270 loss recovery time) can be reduced by 35% using RTOR. These results 271 match those presented in [PGH06][PBP09], where RTOR is shown to 272 significantly reduce retransmission latency. 274 There are also traffic types that do not benefit from RTOR. One 275 example of such traffic is bulk transmission. The reason why bulk 276 traffic does not benefit from RTOR is that such traffic flows mostly 277 have four or more segments outstanding, allowing loss recovery by 278 fast retransmit. However, there is no harm in using RTOR for such 279 traffic as the algorithm only is active when the amount of 280 outstanding and unsent segments are less than rrthresh (default 4). 282 Given that RTOR is a mostly conservative algorithm, it is suitable 283 for experimentation as a system-wide default for TCP traffic. 285 5.2. Spurious Timeouts 287 RTOR can in some situations reduce the loss detection time and 288 thereby increase the risk of spurious timeouts. In theory, the 289 retransmission timer has a lower bound of 1 second [RFC6298], which 290 limits the risk of having spurious timeouts. However, in practice 291 most implementations use a significantly lower value. Initial 292 measurements, show slight increases in the number of spurious 293 timeouts when such lower values are used [RHB15]. However, further 294 experiments, in different environments and with different types of 295 traffic, are encouraged to quantify such increases more reliably. 297 Does a slightly increased risk matter? Generally, spurious timeouts 298 have a negative effect on the network as segments are transmitted 299 needlessly. However, recent experiments do not show a significant 300 increase in network load for a number of realistic scenarios [RHB15]. 301 Another problem with spurious retransmissions is related to the 302 performance of TCP/SCTP, as the congestion window is reduced to one 303 segment when timeouts occur [RFC5681]. This could be a potential 304 problem for applications transmitting multiple bursts of data within 305 a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications. 306 However, results from recent experiments involving persistent web 307 traffic [RHB15] only revealed a net gain of using RTOR. Other types 308 of flows, e.g. long-lived bulk flows, are not affected as the 309 algorithm is only applied when the amount of outstanding and unsent 310 segments is less than rrthresh. Furthermore, short-lived and 311 application-limited flows are typically not affected as they are too 312 short to experience the effect of congestion control or have a 313 transmission rate that is quickly attainable. 315 While a slight increase in spurious timeouts has been observed using 316 RTOR, it is not clear whether the effects of this increase mandate 317 any future algorithmic changes or not -- especially since most modern 318 operating systems already include mechanisms to detect 319 [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems 320 with spurious retransmissions. Further experimentation is needed to 321 determine this and thereby move this specification from experimental 322 to proposed standard. For instance, RTOR has not been evaluated in 323 the context of mobile networks. Mobile networks often incur highly 324 variable RTTs (delay spikes), due to e.g. handovers, and would 325 therefore be a useful scenario for further experimentation. 327 5.3. Tracking Outstanding and Previously Unsent Segments 329 The method of tracking outstanding and previously unsent segments 330 will probably differ depending on the actual TCP implementation. For 331 packet-based TCP implementations, tracking outstanding segments is 332 often straightforward and can be implemented using a simple counter. 334 For byte-based TCP stacks it is a more complex task. Section 3.2 of 335 [RFC5827] outlines a general method of tracking the number of 336 outstanding segments. The same method can be used for RTOR. The 337 implementation will have to track segment boundaries to form an 338 understanding as to how many actual segments have been transmitted, 339 but not acknowledged. This can be done by the sender tracking the 340 boundaries of the rrthresh segments on the right side of the current 341 window (which involves tracking rrthresh + 1 sequence numbers in 342 TCP). This could be done by keeping a circular list of the segment 343 boundaries, for instance. Cumulative ACKs that do not fall within 344 this region indicate that at least rrthresh segments are outstanding, 345 and therefore RTOR is not enabled. When the outstanding window 346 becomes small enough that RTOR can be invoked, a full understanding 347 of the number of outstanding segments will be available from the 348 rrthresh + 1 sequence numbers retained. (Note: the implicit sequence 349 number consumed by the TCP FIN bit can also be included in the 350 tracking of segment boundaries.) 352 Tracking the number of previously unsent segments depends on the 353 segmentation strategy used by the TCP implementation, not whether it 354 is packet-based or byte-based. In the case segments are formed 355 directly on socket writes, the process of determining the number of 356 previously unsent segments should be trivial. In the case that 357 unsent data can be segmented (or re-segmented) as long as it still is 358 unsent, a straightforward strategy could be to divide the amount of 359 unsent data (in bytes) with the SMSS to obtain an estimate. In some 360 cases, such an estimation could be too simplistic, depending on the 361 segmentation strategy of the TCP implementation. However, this 362 estimation is not critical to RTOR. For instance, implementations 363 can use a simplified method by setting prevunsnt to rrthresh whenever 364 previously unsent data is available, and set prevunsnt to zero when 365 no new data is available. This will disable RTOR in the presence of 366 unsent data and only use the number of outstanding segments to 367 enable/disable RTOR. This strategy was used in an earlier version of 368 the algorithm and works well. The addition of tracking prevunsnt was 369 only made to optimize a corner case in which RTOR was unnecessarily 370 disabled. 372 6. Related Work 374 There are several proposals that address the problem of not having 375 enough ACKs for loss recovery. In what follows, we explain why the 376 mechanism described here is complementary to these approaches: 378 The limited transmit mechanism [RFC3042] allows a TCP sender to 379 transmit a previously unsent segment for each of the first two 380 dupACKs. By transmitting new segments, the sender attempts to 381 generate additional dupACKs to enable fast retransmit. However, 382 limited transmit does not help if no previously unsent data is ready 383 for transmission. [RFC5827] specifies an early retransmit algorithm 384 to enable fast loss recovery in such situations. By dynamically 385 lowering the number of dupACKs needed for fast retransmit 386 (dupthresh), based on the number of outstanding segments, a smaller 387 number of dupACKs is needed to trigger a retransmission. In some 388 situations, however, the algorithm is of no use or might not work 389 properly. First, if a single segment is outstanding, and lost, it is 390 impossible to use early retransmit. Second, if ACKs are lost, early 391 retransmit cannot help. Third, if the network path reorders 392 segments, the algorithm might cause more unnecessary retransmissions 393 than fast retransmit. The recommended value of RTOR's rrthresh 394 variable is based on the dupthresh, but is possible to adapt to allow 395 tighter integration with other experimental algorithms such as early 396 retransmit. 398 Tail Loss Probe [TLP] is a proposal to send up to two "probe 399 segments" when a timer fires which is set to a value smaller than the 400 RTO. A "probe segment" is a new segment if new data is available, 401 else a retransmission. The intention is to compensate for sluggish 402 RTO behavior in situations where the RTO greatly exceeds the RTT, 403 which, according to measurements reported in [TLP], is not uncommon. 404 Furthermore, TLP also tries to circumvent the congestion window reset 405 to one segment by instead enabling fast recovery. The Probe timeout 406 (PTO) is normally two RTTs, and a spurious PTO is less risky than a 407 spurious RTO because it would not have the same negative effects 408 (clearing the scoreboard and restarting with slow-start). TLP is a 409 more advanced mechanism than RTOR, requiring e.g. SACK to work, and 410 is often able to reduce loss recovery times more. However, it also 411 increases the amount of spurious retransmissions noticeably, as 412 compared to RTOR [RHB15]. 414 TLP is applicable in situations where RTOR does not apply, and it 415 could overrule (yielding a similar general behavior, but with a lower 416 timeout) RTOR in cases where the number of outstanding segments is 417 smaller than four and no new segments are available for transmission. 418 The PTO has the same inherent problem of restarting the timer on an 419 incoming ACK, and could be combined with a strategy similar to RTOR's 420 to offer more consistent timeouts. 422 7. SCTP Socket API Considerations 424 This section describes how the socket API for SCTP defined in 425 [RFC6458] is extended to control the usage of RTO restart for SCTP. 427 Please note that this section is informational only. 429 7.1. Data Types 431 This section uses data types from [IEEE.1003-1G.1997]: uintN_t means 432 an unsigned integer of exactly N bits (e.g., uint16_t). This is the 433 same as in [RFC6458]. 435 7.2. Socket Option for Controlling the RTO Restart Support 436 (SCTP_RTO_RESTART) 438 This socket option allows the enabling or disabling of RTO Restart 439 for SCTP associations. 441 Whether RTO Restart is enabled or not per default is implementation 442 specific. 444 This socket option uses IPPROTO_SCTP as its level and 445 SCTP_RTO_RESTART as its name. It can be used with getsockopt() and 446 setsockopt(). The socket option value uses the following structure 447 defined in [RFC6458]: 449 struct sctp_assoc_value { 450 sctp_assoc_t assoc_id; 451 uint32_t assoc_value; 452 }; 454 assoc_id: This parameter is ignored for one-to-one style sockets. 455 For one-to-many style sockets, this parameter indicates upon which 456 association the user is performing an action. The special 457 sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in 458 assoc_id for setsockopt(). For getsockopt(), the special value 459 SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to 460 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 462 assoc_value: A non-zero value encodes the enabling of RTO restart 463 whereas a value of 0 encodes the disabling of RTO restart. 465 sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART. 467 8. IANA Considerations 469 This memo includes no request to IANA. 471 9. Security Considerations 473 This document specifies an experimental sender-only modification to 474 TCP and SCTP. The modification introduces a change in how to set the 475 retransmission timer's value when restarted. Therefore, the security 476 considerations found in [RFC6298] apply to this document. No 477 additional security problems have been identified with RTO Restart at 478 this time. 480 10. Acknowledgements 482 The authors wish to thank Michael Tuexen for contributing the SCTP 483 Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark 484 Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, 485 Alexander Zimmermann, and Michael Scharf for commenting on the draft 486 and the ideas behind it. 488 All the authors are supported by RITE (http://riteproject.eu/ ), a 489 research project (ICT-317700) funded by the European Community under 490 its Seventh Framework Program. The views expressed here are those of 491 the author(s) only. The European Commission is not liable for any 492 use that may be made of the information in this document. 494 11. Changes from Previous Versions 496 RFC-Editor note: please remove this section prior to publication. 498 11.1. Changes from draft-ietf-...-06 to -07 500 o Clarified, at multiple places in the document, that the 501 modification is sender-only. 503 o Added an explanation (in the introduction) to why the mechanism is 504 experimental and what experiments are missing. 506 o Added a sentence in Section 4 to clarify that the section is the 507 one describing the actual modification. 509 11.2. Changes from draft-ietf-...-05 to -06 511 o Added socket API considerations, after discussing the draft in 512 tsvwg. 514 11.3. Changes from draft-ietf-...-04 to -05 516 o Introduced variable to track the number of previously unsent 517 segments. 519 o Clarified many concepts, e.g. extended the description on how to 520 track outstanding and previously unsent segments. 522 o Added a reference to initial measurements on the effects of using 523 RTOR. 525 o Improved wording throughout the document. 527 11.4. Changes from draft-ietf-...-03 to -04 529 o Changed the algorithm to allow RTOR when there is unsent data 530 available, but the cwnd does not allow transmission. 532 o Changed the algorithm to not trigger if RTOR <= 0. 534 o Made minor adjustments throughout the document to adjust for the 535 algorithmic change. 537 o Improved the wording throughout the document. 539 11.5. Changes from draft-ietf-...-02 to -03 541 o Updated the document to use "RTOR" instead of "RTO Restart" when 542 refering to the modified algorithm. 544 o Moved document terminology to a section of its own. 546 o Introduced the rrthresh variable in the terminology section. 548 o Added a section to generalize the tracking of outstanding 549 segments. 551 o Updated the algorithm to work when the number of outstanding 552 segments is less than four and one segment is ready for 553 transmission, by restarting the timer when new data has been sent. 555 o Clarified the relationship between fast retransmit and RTOR. 557 o Improved the wording throughout the document. 559 11.6. Changes from draft-ietf-...-01 to -02 561 o Changed the algorithm description in Section 3 to use formal RFC 562 2119 language. 564 o Changed last paragraph of Section 3 to clarify why the RTO restart 565 algorithm is active when less than four segments are outstanding. 567 o Added two paragraphs in Section 4.1 to clarify why the algorithm 568 can be turned on for all TCP traffic without having any negative 569 effects on traffic patterns that do not benefit from a modified 570 timer restart. 572 o Improved the wording throughout the document. 574 o Replaced and updated some references. 576 11.7. Changes from draft-ietf-...-00 to -01 578 o Improved the wording throughout the document. 580 o Removed the possibility for a connection limited by the receiver's 581 advertised window to use RTO restart, decreasing the risk of 582 spurious retransmission timeouts. 584 o Added a section that discusses the applicability of and problems 585 related to the RTO restart mechanism. 587 o Updated the text describing the relationship to TLP to reflect 588 updates made in this draft. 590 o Added acknowledgments. 592 12. References 594 12.1. Normative References 596 [RFC1122] Braden, R., "Requirements for Internet Hosts - 597 Communication Layers", STD 3, RFC 1122, October 1989. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 603 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 604 January 2001. 606 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 607 for TCP", RFC 3522, April 2003. 609 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 610 Acknowledgement (DSACKs) and Stream Control Transmission 611 Protocol (SCTP) Duplicate Transmission Sequence Numbers 612 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 613 February 2004. 615 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 616 for TCP", RFC 4015, February 2005. 618 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 619 4960, September 2007. 621 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 622 Control", RFC 5681, September 2009. 624 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 625 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 626 Spurious Retransmission Timeouts with TCP", RFC 5682, 627 September 2009. 629 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 630 P. Hurtig, "Early Retransmit for TCP and Stream Control 631 Transmission Protocol (SCTP)", RFC 5827, May 2010. 633 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 634 "Computing TCP's Retransmission Timer", RFC 6298, June 635 2011. 637 12.2. Informative References 639 [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- 640 to-End Retransmission Timer for Reliable Unicast 641 Transport", IEEE INFOCOM 2004, March 2004. 643 [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., 644 Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, 645 E., and R. Govindan, "Reducing Web Latency: the Virtue of 646 Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. 648 [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely 649 message delivery?", Springer Telecommunication Systems 47 650 (3-4), August 2011. 652 [IEEE.1003-1G.1997] 653 Institute of Electrical and Electronics Engineers, 654 "Protocol Independent Interfaces", IEEE Standard 1003.1G, 655 March 1997. 657 [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission 658 timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July 659 2000. 661 [P09] Petlund, A., "Improving latency for interactive, thin- 662 stream applications over reliable transport", Unipub PhD 663 Thesis, Oct 2009. 665 [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, 666 C., and P. Halvorsen, "Improving SCTP Retransmission 667 Delays for Time-Dependent Thin Streams", Springer 668 Multimedia Tools and Applications, 45(1-3), 2009. 670 [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, 671 "Considerations of SCTP Retransmission Delays for Thin 672 Streams", IEEE LCN 2006, November 2006. 674 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 675 Yasevich, "Sockets API Extensions for the Stream Control 676 Transmission Protocol (SCTP)", RFC 6458, December 2011. 678 [RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and 679 M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms 680 for TCP", ACM SIGCOMM CCR 45 (1), January 2015. 682 [RJ10] Ramachandran, S., "Web metrics: Size and number of 683 resources", Google 684 http://code.google.com/speed/articles/web-metrics.html, 685 May 2010. 687 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 688 "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of 689 Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- 690 loss-probe-01.txt, February 2013. 692 Authors' Addresses 694 Per Hurtig 695 Karlstad University 696 Universitetsgatan 2 697 Karlstad 651 88 698 Sweden 700 Phone: +46 54 700 23 35 701 Email: per.hurtig@kau.se 703 Anna Brunstrom 704 Karlstad University 705 Universitetsgatan 2 706 Karlstad 651 88 707 Sweden 709 Phone: +46 54 700 17 95 710 Email: anna.brunstrom@kau.se 711 Andreas Petlund 712 Simula Research Laboratory AS 713 P.O. Box 134 714 Lysaker 1325 715 Norway 717 Phone: +47 67 82 82 00 718 Email: apetlund@simula.no 720 Michael Welzl 721 University of Oslo 722 PO Box 1080 Blindern 723 Oslo N-0316 724 Norway 726 Phone: +47 22 85 24 20 727 Email: michawe@ifi.uio.no