idnits 2.17.1 draft-ietf-tcpm-rtorestart-10.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 (November 5, 2015) is 3057 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SEG 1' is mentioned on line 167, but not defined == Missing Reference: 'SEG 2' is mentioned on line 168, but not defined == Missing Reference: 'SEG 3' is mentioned on line 173, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 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: May 8, 2016 A. Petlund 6 Simula Research Laboratory AS 7 M. Welzl 8 University of Oslo 9 November 5, 2015 11 TCP and SCTP RTO Restart 12 draft-ietf-tcpm-rtorestart-10 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 using a smaller timeout 21 duration, so that the effective RTO becomes more aggressive in 22 situations where fast retransmit cannot be used. This enables faster 23 loss detection and recovery for connections that are short-lived or 24 application-limited. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 8, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 TCP and SCTP use two almost identical mechanisms to detect and 61 recover from data loss, specified in [RFC6298][RFC5681] (for TCP) and 62 [RFC4960] (for SCTP). First, if transmitted data is not acknowledged 63 within a certain amount of time, a retransmission timeout (RTO) 64 occurs, and the data is retransmitted. While the RTO is based on 65 measured round-trip times (RTTs) between the sender and receiver, it 66 also has a conservative lower bound of 1 second to ensure that 67 delayed data are not mistaken as lost. Second, when a sender 68 receives duplicate acknowledgments, or similar information via 69 selective acknowledgments, the fast retransmit algorithm suspects 70 data loss and can trigger a retransmission. Duplicate (and 71 selective) acknowledgments are generated by a receiver when data 72 arrives out-of-order. As both data loss and data reordering cause 73 out-of-order arrival, fast retransmit waits for three out-of-order 74 notifications before considering the corresponding data as lost. In 75 some situations, however, the amount of outstanding data is not 76 enough to trigger three such acknowledgments, and the sender must 77 rely on lengthy RTOs for loss recovery. 79 The amount of outstanding data can be small for several reasons: 81 (1) The connection is limited by the congestion control when the 82 path has a low total capacity (bandwidth-delay product) or the 83 connection's share of the capacity is small. It is also limited 84 by the congestion control in the first few RTTs of a connection 85 or after an RTO when the available capacity is probed using 86 slow-start. 88 (2) The connection is limited by the receiver's available buffer 89 space. 91 (3) The connection is limited by the application if the available 92 capacity of the path is not fully utilized (e.g. interactive 93 applications), or at the end of a transfer. 95 While the reasons listed above are valid for any flow, the third 96 reason is most common for applications that transmit short flows, or 97 use a bursty transmission pattern. A typical example of applications 98 that produce short flows are web-based applications. [RJ10] shows 99 that 70% of all web objects, found at the top 500 sites, are too 100 small for fast retransmit to work. [FDT13] shows that about 77% of 101 all retransmissions sent by a major web service are sent after RTO 102 expiry. Applications with bursty transmission patterns often send 103 data in response to actions, or as a reaction to real life events. 104 Typical examples of such applications are stock trading systems, 105 remote computer operations, online games, and web-based applications 106 using persistent connections. What is special about this class of 107 applications is that they often are time-dependant, and extra latency 108 can reduce the application service level [P09]. 110 The RTO Restart (RTOR) mechanism described in this document makes the 111 effective RTO slightly more aggressive when the amount of outstanding 112 data is too small for fast retransmit to work, in an attempt to 113 enable faster loss recovery while being robust to reordering. While 114 RTOR still conforms to the requirement for when a segment can be 115 retransmitted, specified in [RFC6298] (for TCP) and [RFC4960] (for 116 SCTP) it could increase the risk of spurious timeouts. To determine 117 whether this modification is safe to deploy and enable by default, 118 further experimentation is required. Section 5 discusses experiments 119 still needed, including evaluations in environments where the risk of 120 spurious retransmissions are increased e.g. mobile networks with 121 highly varying RTTs. 123 The remainder of this document describes RTOR and its implementation 124 for TCP only, to make the document easier to read. However, the RTOR 125 algorithm described in Section 4 is applicable also for SCTP. 126 Furthermore, Section 7 details the SCTP socket API needed to control 127 RTOR. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 This document introduces the following variables: 137 The number of previously unsent segments (prevunsnt): The number of 138 segments that a sender has queued for transmission, but has not yet 139 sent. 141 RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of 142 the number of outstanding and previously unsent segments (prevunsnt) 143 is below this threshold. 145 3. RTO Overview and Rationale for RTOR 147 The RTO management algorithm described in [RFC6298] recommends that 148 the retransmission timer is restarted when an acknowledgment (ACK) 149 that acknowledges new data is received and there is still outstanding 150 data. The restart is conducted to guarantee that unacknowledged 151 segments will be retransmitted after approximately RTO seconds. The 152 standardized RTO timer management is illustrated in Figure 1 where a 153 TCP sender transmits three segments to a receiver. The arrival of 154 the first and second segment triggers a delayed ACK (delACK) 155 [RFC1122], which restarts the RTO timer at the sender. The RTO is 156 restarted approximately one RTT after the transmission of the third 157 segment. Thus, if the third segment is lost, as indicated in 158 Figure 1, the effective loss detection time become "RTO + RTT" 159 seconds. In some situations, the effective loss detection time 160 becomes even longer. Consider a scenario where only two segments are 161 outstanding. If the second segment is lost, the time to expire the 162 delACK timer will also be included in the effective loss detection 163 time. 165 Sender Receiver 166 ... 167 DATA [SEG 1] ----------------------> (ack delayed) 168 DATA [SEG 2] ----------------------> (send ack) 169 DATA [SEG 3] ----X /-------- ACK 170 (restart RTO) <----------/ 171 ... 172 (RTO expiry) 173 DATA [SEG 3] ----------------------> 175 Figure 1: RTO restart example 177 For bulk traffic the current approach is beneficial -- it is 178 described in [EL04] to act as a "safety margin" that compensates for 179 some of the problems that the authors have identified with the 180 standard RTO calculation. Notably, the authors of [EL04] also state 181 that "this safety margin does not exist for highly interactive 182 applications where often only a single packet is in flight". In 183 general, however, as long as enough segments arrive at a receiver to 184 enable fast retransmit, RTO-based loss recovery should be avoided. 185 RTOs should only be used as a last resort, as they drastically lower 186 the congestion window compared to fast retransmit. 188 Although fast retransmit is preferrable there are situations where 189 timeouts are appropriate, or the only choice. For example, if the 190 network is severely congested and no segments arrive RTO-based 191 recovery should be used. In this situation, the time to recover from 192 the loss(es) will not be the performance bottleneck. However, for 193 connections that do not utilize enough capacity to enable fast 194 retransmit, RTO-based loss detection is the only choice and the time 195 required for this can become a performance bottleneck. 197 4. RTOR Algorithm 199 To enable faster loss recovery for connections that are unable to use 200 fast retransmit, RTOR can be used. This section specifies the 201 modifications required to use RTOR. By resetting the timer to "RTO - 202 T_earliest", where T_earliest is the time elapsed since the earliest 203 outstanding segment was transmitted, retransmissions will always 204 occur after exactly RTO seconds. 206 This document specifies an OPTIONAL sender-only modification to TCP 207 and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a 208 similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender 209 that implements this method MUST follow the algorithm below: 211 When an ACK is received that acknowledges new data: 213 (1) Set T_earliest = 0. 215 (2) If the sum of the number of outstanding and previously unsent 216 segments (prevunsnt) is less than an RTOR threshold 217 (rrthresh), set T_earliest to the time elapsed since the 218 earliest outstanding segment was sent. 220 (3) Restart the retransmission timer so that it will expire after 221 (for the current value of RTO): 223 (a) RTO - T_earliest, if RTO - T_earliest > 0. 225 (b) RTO, otherwise. 227 The RECOMMENDED value of rrthresh is four, as this value will ensure 228 that RTOR is only used when fast retransmit cannot be triggered. 229 With this update, TCP implementations MUST track the time elapsed 230 since the transmission of the earliest outstanding segment 231 (T_earliest). As RTOR is only used when the amount of outstanding 232 and previously unsent data is less than rrthresh segments, TCP 233 implementations also need to track whether the amount of outstanding 234 and previously unsent data is more, equal, or less than rrthresh 235 segments. Although some packet-based TCP implementations (e.g. 237 Linux TCP) already track both the transmission times of all segments 238 and also the number of outstanding segments, not all implementations 239 do. Section 5.3 describes how to implement segment tracking for a 240 general TCP implementation. To use RTOR, the calculated expiration 241 time MUST be positive (step 3(a) in the list above); this is required 242 to ensure that RTOR does not trigger retransmissions prematurely when 243 previously retransmitted segments are acknowledged. 245 5. Discussion 247 Although RTOR conforms to the requirement in [RFC6298] that segments 248 must not be retransmitted earlier than RTO seconds after their 249 original transmission, RTOR makes the effective RTO more aggressive. 250 In this section, we discuss the applicability and the issues related 251 to RTOR. 253 5.1. Applicability 255 The currently standardized algorithm has been shown to add at least 256 one RTT to the loss recovery process in TCP [LS00] and SCTP 257 [HB11][PBP09]. For applications that have strict timing requirements 258 (e.g. interactive web) rather than throughput requirements, using 259 RTOR could be beneficial because the RTT and also the delACK timer of 260 receivers are often large components of the effective loss recovery 261 time. Measurements in [HB11] have shown that the total transfer time 262 of a lost segment (including the original transmission time and the 263 loss recovery time) can be reduced by 35% using RTOR. These results 264 match those presented in [PGH06][PBP09], where RTOR is shown to 265 significantly reduce retransmission latency. 267 There are also traffic types that do not benefit from RTOR. One 268 example of such traffic is bulk transmission. The reason why bulk 269 traffic does not benefit from RTOR is that such traffic flows mostly 270 have four or more segments outstanding, allowing loss recovery by 271 fast retransmit. However, there is no harm in using RTOR for such 272 traffic as the algorithm only is active when the amount of 273 outstanding and unsent segments are less than rrthresh (default 4). 275 Given that RTOR is a mostly conservative algorithm, it is suitable 276 for experimentation as a system-wide default for TCP traffic. 278 5.2. Spurious Timeouts 280 RTOR can in some situations reduce the loss detection time and 281 thereby increase the risk of spurious timeouts. In theory, the 282 retransmission timer has a lower bound of 1 second [RFC6298], which 283 limits the risk of having spurious timeouts. However, in practice 284 most implementations use a significantly lower value. Initial 285 measurements show slight increases in the number of spurious timeouts 286 when such lower values are used [RHB15]. However, further 287 experiments, in different environments and with different types of 288 traffic, are encouraged to quantify such increases more reliably. 290 Does a slightly increased risk matter? Generally, spurious timeouts 291 have a negative effect on the network as segments are transmitted 292 needlessly. However, recent experiments do not show a significant 293 increase in network load for a number of realistic scenarios [RHB15]. 294 Another problem with spurious retransmissions is related to the 295 performance of TCP/SCTP, as the congestion window is reduced to one 296 segment when timeouts occur [RFC5681]. This could be a potential 297 problem for applications transmitting multiple bursts of data within 298 a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications. 299 However, results from recent experiments involving persistent web 300 traffic [RHB15] revealed a net gain of using RTOR. Other types of 301 flows, e.g. long-lived bulk flows, are not affected as the algorithm 302 is only applied when the amount of outstanding and unsent segments is 303 less than rrthresh. Furthermore, short-lived and application-limited 304 flows are typically not affected as they are too short to experience 305 the effect of congestion control or have a transmission rate that is 306 quickly attainable. 308 While a slight increase in spurious timeouts has been observed using 309 RTOR, it is not clear whether the effects of this increase mandate 310 any future algorithmic changes or not -- especially since most modern 311 operating systems already include mechanisms to detect 312 [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems 313 with spurious retransmissions. Further experimentation is needed to 314 determine this and thereby move this specification from experimental 315 to the standards track. For instance, RTOR has not been evaluated in 316 the context of mobile networks. Mobile networks often incur highly 317 variable RTTs (delay spikes), due to e.g. handovers, and would 318 therefore be a useful scenario for further experimentation. 320 5.3. Tracking Outstanding and Previously Unsent Segments 322 The method of tracking outstanding and previously unsent segments 323 will probably differ depending on the actual TCP implementation. For 324 packet-based TCP implementations, tracking outstanding segments is 325 often straightforward and can be implemented using a simple counter. 326 For byte-based TCP stacks it is a more complex task. Section 3.2 of 327 [RFC5827] outlines a general method of tracking the number of 328 outstanding segments. The same method can be used for RTOR. The 329 implementation will have to track segment boundaries to form an 330 understanding as to how many actual segments have been transmitted, 331 but not acknowledged. This can be done by the sender tracking the 332 boundaries of the rrthresh segments on the right side of the current 333 window (which involves tracking rrthresh + 1 sequence numbers in 334 TCP). This could be done by keeping a circular list of the segment 335 boundaries, for instance. Cumulative ACKs that do not fall within 336 this region indicate that at least rrthresh segments are outstanding, 337 and therefore RTOR is not enabled. When the outstanding window 338 becomes small enough that RTOR can be invoked, a full understanding 339 of the number of outstanding segments will be available from the 340 rrthresh + 1 sequence numbers retained. (Note: the implicit sequence 341 number consumed by the TCP FIN bit can also be included in the 342 tracking of segment boundaries.) 344 Tracking the number of previously unsent segments depends on the 345 segmentation strategy used by the TCP implementation, not whether it 346 is packet-based or byte-based. In the case segments are formed 347 directly on socket writes, the process of determining the number of 348 previously unsent segments should be trivial. In the case that 349 unsent data can be segmented (or re-segmented) as long as it still is 350 unsent, a straightforward strategy could be to divide the amount of 351 unsent data (in bytes) with the SMSS to obtain an estimate. In some 352 cases, such an estimation could be too simplistic, depending on the 353 segmentation strategy of the TCP implementation. However, this 354 estimation is not critical to RTOR. The tracking of prevunsnt is 355 only made to optimize a corner case in which RTOR was unnecessarily 356 disabled. Implementations can use a simplified method by setting 357 prevunsnt to rrthresh whenever previously unsent data is available, 358 and set prevunsnt to zero when no new data is available. This will 359 disable RTOR in the presence of unsent data and only use the number 360 of outstanding segments to enable/disable RTOR. 362 6. Related Work 364 There are several proposals that address the problem of not having 365 enough ACKs for loss recovery. In what follows, we explain why the 366 mechanism described here is complementary to these approaches: 368 The limited transmit mechanism [RFC3042] allows a TCP sender to 369 transmit a previously unsent segment for each of the first two 370 dupACKs. By transmitting new segments, the sender attempts to 371 generate additional dupACKs to enable fast retransmit. However, 372 limited transmit does not help if no previously unsent data is ready 373 for transmission. [RFC5827] specifies an early retransmit algorithm 374 to enable fast loss recovery in such situations. By dynamically 375 lowering the number of dupACKs needed for fast retransmit 376 (dupthresh), based on the number of outstanding segments, a smaller 377 number of dupACKs is needed to trigger a retransmission. In some 378 situations, however, the algorithm is of no use or might not work 379 properly. First, if a single segment is outstanding, and lost, it is 380 impossible to use early retransmit. Second, if ACKs are lost, early 381 retransmit cannot help. Third, if the network path reorders 382 segments, the algorithm might cause more spurious retransmissions 383 than fast retransmit. The recommended value of RTOR's rrthresh 384 variable is based on the dupthresh, but is possible to adapt to allow 385 tighter integration with other experimental algorithms such as early 386 retransmit. 388 Tail Loss Probe [TLP] is a proposal to send up to two "probe 389 segments" when a timer fires which is set to a value smaller than the 390 RTO. A "probe segment" is a new segment if new data is available, 391 else a retransmission. The intention is to compensate for sluggish 392 RTO behavior in situations where the RTO greatly exceeds the RTT, 393 which, according to measurements reported in [TLP], is not uncommon. 394 Furthermore, TLP also tries to circumvent the congestion window reset 395 to one segment by instead enabling fast recovery. The Probe timeout 396 (PTO) is normally two RTTs, and a spurious PTO is less risky than a 397 spurious RTO because it would not have the same negative effects 398 (clearing the scoreboard and restarting with slow-start). TLP is a 399 more advanced mechanism than RTOR, requiring e.g. SACK to work, and 400 is often able to reduce loss recovery times more. However, it also 401 increases the amount of spurious retransmissions noticeably, as 402 compared to RTOR [RHB15]. 404 TLP is applicable in situations where RTOR does not apply, and it 405 could overrule (yielding a similar general behavior, but with a lower 406 timeout) RTOR in cases where the number of outstanding segments is 407 smaller than four and no new segments are available for transmission. 408 The PTO has the same inherent problem of restarting the timer on an 409 incoming ACK, and could be combined with a strategy similar to RTOR's 410 to offer more consistent timeouts. 412 7. SCTP Socket API Considerations 414 This section describes how the socket API for SCTP defined in 415 [RFC6458] is extended to control the usage of RTO restart for SCTP. 417 Please note that this section is informational only. 419 7.1. Data Types 421 This section uses data types from [IEEE.1003-1G.1997]: uintN_t means 422 an unsigned integer of exactly N bits (e.g., uint16_t). This is the 423 same as in [RFC6458]. 425 7.2. Socket Option for Controlling the RTO Restart Support 426 (SCTP_RTO_RESTART) 428 This socket option allows the enabling or disabling of RTO Restart 429 for SCTP associations. 431 Whether RTO Restart is enabled or not per default is implementation 432 specific. 434 This socket option uses IPPROTO_SCTP as its level and 435 SCTP_RTO_RESTART as its name. It can be used with getsockopt() and 436 setsockopt(). The socket option value uses the following structure 437 defined in [RFC6458]: 439 struct sctp_assoc_value { 440 sctp_assoc_t assoc_id; 441 uint32_t assoc_value; 442 }; 444 assoc_id: This parameter is ignored for one-to-one style sockets. 445 For one-to-many style sockets, this parameter indicates upon which 446 association the user is performing an action. The special 447 sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in 448 assoc_id for setsockopt(). For getsockopt(), the special value 449 SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to 450 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 452 assoc_value: A non-zero value encodes the enabling of RTO restart 453 whereas a value of 0 encodes the disabling of RTO restart. 455 sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART. 457 8. IANA Considerations 459 This memo includes no request to IANA. 461 9. Security Considerations 463 This document specifies an experimental sender-only modification to 464 TCP and SCTP. The modification introduces a change in how to set the 465 retransmission timer's value when restarted. Therefore, the security 466 considerations found in [RFC6298] apply to this document. No 467 additional security problems have been identified with RTO Restart at 468 this time. 470 10. Acknowledgements 472 The authors wish to thank Michael Tuexen for contributing the SCTP 473 Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark 474 Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, 475 Alexander Zimmermann, and Michael Scharf for commenting on the draft 476 and the ideas behind it. 478 All the authors are supported by RITE (http://riteproject.eu/ ), a 479 research project (ICT-317700) funded by the European Community under 480 its Seventh Framework Program. The views expressed here are those of 481 the author(s) only. The European Commission is not liable for any 482 use that may be made of the information in this document. 484 11. Changes from Previous Versions 486 RFC-Editor note: please remove this section prior to publication. 488 11.1. Changed from draft-ietf-...-09 to -10 490 o Changed wording in abstract, from "delay" to "timeout duration". 492 11.2. Changed from draft-ietf-...-08 to -09 494 o Clarified, in the abstract, that the modified restart causes a 495 smaller retransmission delay in total. 497 o Clarified, in the introduction, that the fast retransmit algorithm 498 may cause retransmissions upon receiving duplicate 499 acknowledgments, not that it unconditionally does so. 501 o Changed wording from "to proposed standard" to "to the standards 502 track". 504 o Changed algorithm description so that a TCP sender MUST track the 505 time elapsed since the transmission of the earliest outstanding 506 segment. This was not explicitly stated in previous versions of 507 the draft. 509 11.3. Changes from draft-ietf-...-07 to -08 511 o Clarified, at multiple places in the document, that the 512 modification only causes the effective RTO to be more aggressive, 513 not the actual RTO. 515 o Removed information in the introduction that was too detailed, 516 i.e., material that is hard to understand without knowing details 517 of the algorithm. 519 o Changed the name of Section 3 to more correctly capture the actual 520 contents of the section. 522 o Re-arranged the text in Section 3 to have a more logical 523 structure. 525 o Moved text from the algorithm description (Section 4) to the 526 introduction of the discussion section (Section 5). The text was 527 discussing the possible effects of the algorithm more than 528 describing the actual algorithm. 530 o Clarified why the RECOMMENDED value of rrthresh is four. 532 o Reworked the introduction to be suitable for both TCP and SCTP. 534 11.4. Changes from draft-ietf-...-06 to -07 536 o Clarified, at multiple places in the document, that the 537 modification is sender-only. 539 o Added an explanation (in the introduction) to why the mechanism is 540 experimental and what experiments are missing. 542 o Added a sentence in Section 4 to clarify that the section is the 543 one describing the actual modification. 545 11.5. Changes from draft-ietf-...-05 to -06 547 o Added socket API considerations, after discussing the draft in 548 tsvwg. 550 11.6. Changes from draft-ietf-...-04 to -05 552 o Introduced variable to track the number of previously unsent 553 segments. 555 o Clarified many concepts, e.g. extended the description on how to 556 track outstanding and previously unsent segments. 558 o Added a reference to initial measurements on the effects of using 559 RTOR. 561 o Improved wording throughout the document. 563 11.7. Changes from draft-ietf-...-03 to -04 565 o Changed the algorithm to allow RTOR when there is unsent data 566 available, but the cwnd does not allow transmission. 568 o Changed the algorithm to not trigger if RTOR <= 0. 570 o Made minor adjustments throughout the document to adjust for the 571 algorithmic change. 573 o Improved the wording throughout the document. 575 11.8. Changes from draft-ietf-...-02 to -03 577 o Updated the document to use "RTOR" instead of "RTO Restart" when 578 refering to the modified algorithm. 580 o Moved document terminology to a section of its own. 582 o Introduced the rrthresh variable in the terminology section. 584 o Added a section to generalize the tracking of outstanding 585 segments. 587 o Updated the algorithm to work when the number of outstanding 588 segments is less than four and one segment is ready for 589 transmission, by restarting the timer when new data has been sent. 591 o Clarified the relationship between fast retransmit and RTOR. 593 o Improved the wording throughout the document. 595 11.9. Changes from draft-ietf-...-01 to -02 597 o Changed the algorithm description in Section 3 to use formal RFC 598 2119 language. 600 o Changed last paragraph of Section 3 to clarify why the RTO restart 601 algorithm is active when less than four segments are outstanding. 603 o Added two paragraphs in Section 4.1 to clarify why the algorithm 604 can be turned on for all TCP traffic without having any negative 605 effects on traffic patterns that do not benefit from a modified 606 timer restart. 608 o Improved the wording throughout the document. 610 o Replaced and updated some references. 612 11.10. Changes from draft-ietf-...-00 to -01 614 o Improved the wording throughout the document. 616 o Removed the possibility for a connection limited by the receiver's 617 advertised window to use RTO restart, decreasing the risk of 618 spurious retransmission timeouts. 620 o Added a section that discusses the applicability of and problems 621 related to the RTO restart mechanism. 623 o Updated the text describing the relationship to TLP to reflect 624 updates made in this draft. 626 o Added acknowledgments. 628 12. References 630 12.1. Normative References 632 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 633 Communication Layers", STD 3, RFC 1122, 634 DOI 10.17487/RFC1122, October 1989, 635 . 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, 639 DOI 10.17487/RFC2119, March 1997, 640 . 642 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 643 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 644 DOI 10.17487/RFC3042, January 2001, 645 . 647 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 648 for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, 649 . 651 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 652 Acknowledgement (DSACKs) and Stream Control Transmission 653 Protocol (SCTP) Duplicate Transmission Sequence Numbers 654 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 655 DOI 10.17487/RFC3708, February 2004, 656 . 658 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 659 for TCP", RFC 4015, DOI 10.17487/RFC4015, February 2005, 660 . 662 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 663 RFC 4960, DOI 10.17487/RFC4960, September 2007, 664 . 666 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 667 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 668 . 670 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 671 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 672 Spurious Retransmission Timeouts with TCP", RFC 5682, 673 DOI 10.17487/RFC5682, September 2009, 674 . 676 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 677 P. Hurtig, "Early Retransmit for TCP and Stream Control 678 Transmission Protocol (SCTP)", RFC 5827, 679 DOI 10.17487/RFC5827, May 2010, 680 . 682 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 683 "Computing TCP's Retransmission Timer", RFC 6298, 684 DOI 10.17487/RFC6298, June 2011, 685 . 687 12.2. Informative References 689 [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- 690 to-End Retransmission Timer for Reliable Unicast 691 Transport", IEEE INFOCOM 2004, March 2004. 693 [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., 694 Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, 695 E., and R. Govindan, "Reducing Web Latency: the Virtue of 696 Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. 698 [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely 699 message delivery?", Springer Telecommunication Systems 47 700 (3-4), August 2011. 702 [IEEE.1003-1G.1997] 703 Institute of Electrical and Electronics Engineers, 704 "Protocol Independent Interfaces", IEEE Standard 1003.1G, 705 March 1997. 707 [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission 708 timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July 709 2000. 711 [P09] Petlund, A., "Improving latency for interactive, thin- 712 stream applications over reliable transport", Unipub PhD 713 Thesis, Oct 2009. 715 [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, 716 C., and P. Halvorsen, "Improving SCTP Retransmission 717 Delays for Time-Dependent Thin Streams", 718 Springer Multimedia Tools and Applications, 45(1-3), 2009. 720 [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, 721 "Considerations of SCTP Retransmission Delays for Thin 722 Streams", IEEE LCN 2006, November 2006. 724 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 725 Yasevich, "Sockets API Extensions for the Stream Control 726 Transmission Protocol (SCTP)", RFC 6458, 727 DOI 10.17487/RFC6458, December 2011, 728 . 730 [RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and 731 M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms 732 for TCP", ACM SIGCOMM CCR 45 (1), January 2015. 734 [RJ10] Ramachandran, S., "Web metrics: Size and number of 735 resources", Google http://code.google.com/speed/articles/ 736 web-metrics.html, May 2010. 738 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 739 "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of 740 Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- 741 loss-probe-01.txt, February 2013. 743 Authors' Addresses 745 Per Hurtig 746 Karlstad University 747 Universitetsgatan 2 748 Karlstad 651 88 749 Sweden 751 Phone: +46 54 700 23 35 752 Email: per.hurtig@kau.se 753 Anna Brunstrom 754 Karlstad University 755 Universitetsgatan 2 756 Karlstad 651 88 757 Sweden 759 Phone: +46 54 700 17 95 760 Email: anna.brunstrom@kau.se 762 Andreas Petlund 763 Simula Research Laboratory AS 764 P.O. Box 134 765 Lysaker 1325 766 Norway 768 Phone: +47 67 82 82 00 769 Email: apetlund@simula.no 771 Michael Welzl 772 University of Oslo 773 PO Box 1080 Blindern 774 Oslo N-0316 775 Norway 777 Phone: +47 22 85 24 20 778 Email: michawe@ifi.uio.no