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