idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-response-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2861], [RFC2581], [WS95], [RFC793], [RFC2119], [RFC2988], [RFC3390]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) ** Downref: Normative reference to an Experimental RFC: RFC 3522 ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-07) exists of draft-allman-tcp-early-rexmt-03 -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Reiner Ludwig 3 INTERNET-DRAFT Ericsson Research 4 Expires: September 2004 Andrei Gurtov 5 TeliaSonera 6 March, 2004 8 The Eifel Response Algorithm for TCP 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 Based on an appropriate detection algorithm, the Eifel response 34 algorithm provides a way for a TCP sender to respond to a detected 35 spurious timeout. It adapts the retransmission timer to avoid further 36 spurious timeouts, and can avoid - depending on the detection 37 algorithm - the often unnecessary go-back-N retransmits that would 38 otherwise be sent. In addition, the Eifel response algorithm restores 39 the congestion control state in such a way that packet bursts are 40 avoided. 42 Terminology 44 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 45 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 46 document, are to be interpreted as described in [RFC2119]. 48 We refer to the first-time transmission of an octet as the 'original 49 transmit'. A subsequent transmission of the same octet is referred to 50 as a 'retransmit'. In most cases this terminology can likewise be 51 applied to data segments as opposed to octets. However, when 52 repacketization occurs, a segment can contain both first-time 53 transmissions and retransmissions of octets. In that case, this 54 terminology is only consistent when applied to octets. For the Eifel 55 detection and response algorithms this makes no difference as they 56 also operate correctly when repacketization occurs. 58 We use the term 'acceptable ACK' as defined in [RFC793]. That is an 59 ACK that acknowledges previously unacknowledged data. We use the term 60 'bytes_acked' to refer to the amount (in terms of octets) of 61 previously unacknowledged data that is acknowledged by the most 62 recently received acceptable ACK. We use the TCP sender state 63 variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA 64 holds the segment sequence number of the oldest outstanding segment. 65 SND.NXT holds the segment sequence number of the next segment the TCP 66 sender will (re-)transmit. In addition, we define as 'SND.MAX' the 67 segment sequence number of the next original transmit to be sent. The 68 definition of SND.MAX is equivalent to the definition of 'snd_max' in 69 [WS95]. 71 We use the TCP sender state variables 'cwnd' (congestion window), and 72 'ssthresh' (slow-start threshold), and the term 'FlightSize' as 73 defined in [RFC2581]. We use the term 'Initial Window (IW)' as 74 defined in [RFC3390]. FlightSize is the amount (in terms of octets) 75 of outstanding data at a given point in time. The IW is the size of 76 the sender's congestion window after the three-way handshake is 77 completed. We use the TCP sender state variables 'SRTT' and 'RTTVAR', 78 and the terms 'RTO' and 'G' as defined in [RFC2988]. G is the clock 79 granularity of the retransmission timer. In addition, we assume that 80 the TCP sender maintains in the (local) variable 'RTT-SAMPLE' the 81 value of the latest round-trip time (RTT) measurement. 83 We use the TCP sender state variable 'T_last', and the term 'tcpnow' 84 as used in [RFC2861]. T_last holds the time when the TCP sender sent 85 the last data segment while tcpnow is the TCP sender's current 86 "system time". 88 1. Introduction 90 The Eifel response algorithm relies on a detection algorithm such as 91 the Eifel detection algorithm defined in [RFC3522]. That document 92 discusses the relevant background and motivation that also applies to 93 this document. Hence, the reader is expected to be familiar with 94 [RFC3522]. Note that alternative response algorithms have been 95 proposed [BA02] that could also rely on the Eifel detection 96 algorithm, and vice versa alternative detection algorithms have been 97 proposed [RFC3708], [SK04] that could work together with the Eifel 98 response algorithm. 100 Based on an appropriate detection algorithm, the Eifel response 101 algorithm provides a way for a TCP sender to respond to a detected 102 spurious timeout. It adapts the retransmission timer to avoid further 103 spurious timeouts, and can avoid - depending on the detection 104 algorithm - the often unnecessary go-back-N retransmits that would 105 otherwise be sent. In addition, the Eifel response algorithm restores 106 the congestion control state in such a way that packet bursts are 107 avoided. 109 Note: A previous version of the Eifel response algorithm also 110 included a response to a detected spurious fast retransmit. 111 However, since a consensus was not reached about how to adapt the 112 duplicate acknowledgement threshold in that case, that part of the 113 algorithm was removed for the time being. 115 2. Interworking with Detection Algorithms 117 If the Eifel response algorithm is implemented at the TCP sender, it 118 MUST be implemented together with a detection algorithm that is 119 specified in an RFC. 121 Designers of detection algorithms who want their algorithms to work 122 together with the Eifel response algorithm should reuse the variable 123 "SpuriousRecovery" with the semantics and defined values specified in 124 [RFC3522]. In addition, we define LATE_SPUR_TO (equal -1) as another 125 possible value of the variable SpuriousRecovery. Detection algorithms 126 should set the value of SpuriousRecovery to LATE_SPUR_TO if the 127 detection of a spurious retransmit is based upon receiving the ACK 128 for the retransmit (as opposed to an ACK for an original transmit). 129 For example, this applies to detection algorithms that are based on 130 the DSACK option [RFC3708]. 132 3. The Eifel Response Algorithm 134 The complete algorithm is specified in section 3.1. In sections 135 3.2-3.6, we motivate the different steps of the algorithm. 137 3.1. The Algorithm 139 Given that a TCP sender has enabled a detection algorithm that 140 complies with the requirements set in Section 2, a TCP sender MAY use 141 the Eifel response algorithm as defined in this subsection. 143 If the Eifel response algorithm is used, the following steps MUST be 144 taken by the TCP sender, but only upon initiation of a timeout-based 145 loss recovery. That is when the first timeout-based retransmit is 146 sent. I.e., the algorithm MUST NOT be reinitiated after a timeout- 147 based loss recovery has already started. In particular, it may not be 148 reinitiated upon subsequent timeouts for the same segment, and not 149 upon retransmitting segments other than the oldest outstanding 150 segment. 152 (0) Before the variables cwnd and ssthresh get updated when 153 loss recovery is initiated, set a "pipe_prev" variable as 154 follows: 155 pipe_prev <- max (FlightSize, ssthresh) 157 Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as 158 follows: 159 SRTT_prev <- SRTT + (2 * G) 160 RTTVAR_prev <- RTTVAR 162 (DET) This is a placeholder for a detection algorithm that must 163 be executed at this point. In case [RFC3522] is used as 164 the detection algorithm, steps (1) - (6) of that algorithm 165 go here. 167 (7) If SpuriousRecovery equals SPUR_TO, then 168 proceed to step (8), 170 else if SpuriousRecovery equals LATE_SPUR_TO, then 171 proceed to step (9), 173 else 174 proceed to step (DONE). 176 (8) Resume the transmission with previously unsent data: 178 Set 179 SND.NXT <- SND.MAX 181 (9) Reversing the congestion control state: 183 If the acceptable ACK has the ECN-Echo flag [RFC3168] set, 184 then 185 proceed to step (DONE), 187 else set 188 cwnd <- FlightSize + min (bytes_acked, IW) 189 ssthresh <- pipe_prev 191 Proceed to step (DONE). 193 (10) Interworking with Congestion Window Validation: 195 If congestion window validation is implemented according 196 to [RFC2861], then set 197 T_last <- tcpnow 199 (11) Adapt the Conservativeness of the Retransmission Timer: 201 Upon the first RTT-SAMPLE taken from new data, i.e., the 202 first RTT-SAMPLE that can be derived from an acceptable 203 ACK for data that was previously unsent when the spurious 204 timeout occurred, 206 if the retransmission timer is implemented according 207 to [RFC2988], then set 208 SRTT <- max (SRTT_prev, RTT-SAMPLE) 209 RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2) 210 RTO <- SRTT + max (G, 4*RTTVAR) 212 Run the bounds check on the RTO (rules (2.4) and 213 (2.5) in [RFC2988]), and restart the 214 retransmission timer, 216 else 217 Appropriately adapt the conservativeness of the 218 retransmission timer that is implemented. 220 (DONE) No further processing. 222 3.2 Storing the Current Congestion Control State (step 0) 224 The TCP sender stores in pipe_prev what is considered a safe slow- 225 start threshold (ssthresh) before loss recovery is initiated, i.e., 226 before the loss indication is taken into account. This is either the 227 current FlightSize if the TCP sender is in congestion avoidance or 228 the current ssthresh if the TCP sender is in slow-start. If the TCP 229 sender later detects that it has entered loss recovery unnecessarily, 230 then pipe_prev is used in step (9) to reverse the congestion control 231 state. Thus, until the loss recovery phase is terminated, pipe_prev 232 maintains a memory of the congestion control state of the time right 233 before the loss recovery phase was initiated. A similar approach is 234 proposed in [RFC2861], where this state is stored in ssthresh 235 directly after a TCP sender has become idle or application-limited. 237 There had been debates about whether the value of pipe_prev should be 238 decayed over time, e.g., upon subsequent timeouts for the same 239 outstanding segment. We do not require the decaying of pipe_prev for 240 the Eifel response algorithm, and do not believe that such a 241 conservative approach should be in place. Instead, we follow the idea 242 of revalidating the congestion window through slow-start as suggested 243 in [RFC2861]. That is, in step (9), the cwnd is reset to a value that 244 avoids large packet bursts, while ssthresh is reset to the value of 245 pipe_prev. Note that [RFC2581] and [RFC2861] also do not require a 246 decaying of ssthresh after it has been reset in response to a loss 247 indication, or after a TCP sender has become idle or application- 248 limited. 250 3.3 Suppressing the Unnecessary go-back-N Retransmits (step 8) 252 Without the use of the TCP timestamps option [RFC1323], the TCP 253 sender suffers from the retransmission ambiguity problem [Zh86], 254 [KP87]. Hence, when the first acceptable ACK arrives after a spurious 255 timeout, the TCP sender must assume that this ACK was sent in 256 response to the retransmit when in fact it was sent in response to an 257 original transmit. Furthermore, the TCP sender must further assume 258 that all other segments outstanding at that point were lost. 260 Note: Except for certain cases where original ACKs were lost, the 261 first acceptable ACK cannot carry a DSACK option [RFC2883]. 263 Consequently, once the TCP sender's state has been updated after the 264 first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is 265 what causes the often unnecessary go-back-N retransmits. From that 266 point on every arriving acceptable ACK that was sent in response to 267 an original transmit will advance SND.NXT. But as long as SND.NXT is 268 smaller than the value that SND.MAX had when the timeout occurred, 269 those ACKs will clock out retransmits, whether those segments were 270 lost or not. 272 In fact, during this phase the TCP sender breaks 'packet 273 conservation' [Jac88]. This is because the go-back-N retransmits are 274 sent during slow-start. I.e., for each original transmit leaving the 275 network, two retransmits are sent into the network as long as SND.NXT 276 does not equal SND.MAX (see [LK00] for more detail). 278 Once a spurious timeout has been detected (based upon receiving an 279 ACK for an original transmit), it is therefore safe to let the TCP 280 sender resume the transmission with previously unsent data. Thus, the 281 Eifel response algorithm changes the TCP sender's state by setting 282 SND.NXT to SND.MAX in that case. Note that this step is only executed 283 if the variable SpuriousRecovery equals SPUR_TO, which in turn 284 requires a detection algorithm such as the Eifel detection algorithm 285 [RFC3522] or the F-RTO algorithm [SK04] that detects a spurious 286 retransmit based upon receiving an ACK for an original transmit (as 287 opposed to the ACK for the retransmit [RFC3708]). 289 3.4 Reversing the Congestion Control State (step 9) 291 When a TCP sender enters loss recovery, it also assumes that is has 292 received a congestion indication. In response to that it reduces 293 cwnd, and ssthresh. However, once the TCP sender detects that the 294 loss recovery has been falsely triggered, this reduction was 295 unnecessary. In fact, no congestion indication has been received. We 296 therefore believe that it is safe to revert to the previous 297 congestion control state following the approach of revalidating the 298 congestion window as outlined below. This is unless the acceptable 299 ACK signals congestion through the ECN-Echo flag [RFC3168]. In that 300 case, the TCP sender MUST refrain from reversing congestion control 301 state. 303 If the ECN-Echo flag is not set, cwnd is reset to the sum of the 304 current FlightSize and the minimum of bytes_acked and IW. Recall that 305 bytes_acked is the number of bytes that have been acknowledged by the 306 acceptable ACK. Note that the value of cwnd must not be changed any 307 further for that ACK, and that the value of FlightSize at this point 308 in time may be different from the value of FlightSize in step (0). 309 The value of IW puts a limit on the size of the packet burst that the 310 TCP sender may send into the network after the Eifel response 311 algorithm has terminated. The value of IW is considered an acceptable 312 burst size. It is the amount of data that a TCP sender may send into 313 a yet "unprobed" network at the beginning of a connection. 315 Then ssthresh is reset to the value of pipe_prev. As a result, the 316 TCP sender either immediately resumes probing the network for more 317 bandwidth in congestion avoidance, or it first slow-starts to what is 318 considered a safe operating point for the congestion window. In some 319 cases, this can mean that the first few acceptable ACKs that arrive 320 will not clock out any data segments. 322 3.5 Interworking with the CWV Algorithm (step 10) 324 An implementation of the Congestion Window Validation (CWV) algorithm 325 [RFC2861] could potentially misinterpret a delay spike that caused a 326 spurious timeout as a phase where the TCP sender had been idle. 327 Therefore, T_last is reset to prevent the triggering of the CWV 328 algorithm in this case. 330 Note: The term 'idle' implies that the TCP sender has no data 331 outstanding, i.e., all data sent has been acknowledged [Jac88]. 332 According to this definition, a TCP sender is not idle while it is 333 waiting for an acceptable ACK after a timeout. Unfortunately, the 334 pseudo-code in [RFC2861] does not include a check for the 335 condition "idle" (SND.UNA == SND.MAX). We therefore had to add 336 step (10) to the Eifel response algorithm. 338 3.6 Adapting the Retransmission Timer (step 11) 340 There is currently only one retransmission timer standardized for TCP 341 [RFC2988]. We therefore only address that timer explicitly. Future 342 standards that might define alternatives to [RFC2988] should propose 343 similar measures to adapt the conservativeness of the retransmission 344 timer. 346 A spurious timeout often results from a delay spike, which is a 347 sudden increase of the RTT that usually cannot be predicted. After a 348 delay spike the RTT may have changed permanently, e.g., due to a path 349 change, or because the available bandwidth on a bandwidth-dominated 350 path has decreased. This may often occur with wide-area wireless 351 access links. In this case, the RTT estimators (SRTT and RTTVAR) 352 should be reinitialized from the first RTT-SAMPLE taken from new data 353 according to rule (2.2) of [RFC2988]. That is, from the first RTT- 354 SAMPLE that can be derived from an acceptable ACK for data that was 355 previously unsent when the spurious timeout occurred. 357 However, a delay spike may only indicate a transient phase, after 358 which the RTT returns to its previous range of values, or even to 359 smaller values. Also, a spurious timeout may occur because the TCP 360 sender's RTT estimators were only inaccurate, so that the 361 retransmission timer expires "a tad too early". We believe that two 362 times the clock granularity of the retransmission timer (2 * G) is a 363 reasonable upper bound on "a tad too early". Thus, when the new RTO 364 is calculated in step (11) we ensure that it is at least (2 * G) 365 greater (see also step (0)) than the RTO was before the spurious 366 timeout occurred. 368 Note that other TCP sender processing will usually take place between 369 steps (10) and (11). During this phase, i.e., before step (11) has 370 been reached, the RTO is managed according to the rules of [RFC2988]. 371 We believe that this is sufficiently conservative for the following 372 reasons. First, the retransmission timer is restarted upon the 373 acceptable ACK that was used to detect the spurious timeout. As a 374 result, the delay spike is already implicitly factored in for 375 segments outstanding at that time. This is discussed in more in 376 detail in [EL04] where this effect is called the "RTO offset". 377 Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE 378 can be derived from that acceptable ACK. This RTT-SAMPLE must be 379 relatively large since it includes the delay spike that caused the 380 spurious timeout. Consequently, the RTT estimators will be updated 381 rather conservatively. Without timestamps the RTO will stay 382 conservatively backed-off due to Karn's algorithm [RFC2988] until the 383 first RTT-SAMPLE that can be derived from an acceptable ACK for data 384 that was previously unsent when the spurious timeout occurred. 386 To have the new RTO become effective, the retransmission timer needs 387 to be restarted. This is consistent with [RFC2988] which recommends 388 restarting the retransmission timer with the arrival of an acceptable 389 ACK. 391 4. Advanced Loss Recovery is Crucial for the Eifel Response Algorithm 392 We have studied environments where spurious timeouts and multiple 393 losses from the same flight of packets often coincide [GL02], [GL03]. 394 In such a case the oldest outstanding segment does arrive at the TCP 395 receiver, but one or more packets from the remaining outstanding 396 flight are lost. In those environments, TCP-Reno's performance 397 suffers if the Eifel response algorithm is operated without an 398 advanced loss recovery scheme such as a SACK-based scheme [RFC3517] 399 or NewReno [FHG03]. The reason is TCP-Reno's aggressiveness after a 400 spurious timeout. Even though it breaks 'packet conservation' (see 401 Section 3.3) when blindly retransmitting all outstanding segments, it 402 usually recovers all packets lost from that flight within a single 403 round-trip time. On the contrary, the more conservative 404 TCP-Reno-with-Eifel is often forced into another timeout. Thus, we 405 recommend to always operate the Eifel response algorithm in 406 combination with [RFC3517] or [FHG03]. Additional robustness to 407 multiple losses from the same flight is achieved with the Limited 408 Transmit and Early Retransmit algorithms [RFC3042], [AAAB04]. 410 Note: The SACK-based scheme we used for our simulations in [GL02] 411 and [GL03] is different from the SACK-based scheme that later got 412 standardized [RFC3517]. The key difference is that [RFC3517] is 413 more robust to multiple losses from the same flight. It is less 414 conservative in declaring that a packet has left the network, and 415 is therefore less dependent on timeouts to recover genuine packet 416 losses. 418 In case the NewReno algorithm [FHG03] is used in combination with the 419 Eifel response algorithm, step 1) of the NewReno algorithm SHOULD be 420 modified as follows, but only if SpuriousRecovery equals SPUR_TO: 422 1) Three duplicate ACKs: 423 When the third duplicate ACK is received and the sender is not 424 already in the Fast Recovery procedure, go to Step 1A. 426 That is, the entire step 1B) of the NewReno algorithm is obsolete 427 because step (8) of the Eifel response algorithm avoids the case 428 where three duplicate ACKs result from unnecessary go-back-N 429 retransmits after a timeout. Step (8) of the Eifel response algorithm 430 avoids such unnecessary go-back-N retransmits in the first place. 431 However, recall that step (8) is only executed if the variable 432 SpuriousRecovery equals SPUR_TO, which in turn requires a detection 433 algorithm such as the Eifel detection algorithm [RFC3522] or the 434 F-RTO algorithm [SK04] that detects a spurious retransmit based upon 435 receiving an ACK for an original transmit (as opposed to the ACK for 436 the retransmit [RFC3708]). 438 5. IPR Considerations 440 The IETF has been notified of intellectual property rights claimed in 441 regard to some or all of the specification contained in this 442 document. For more information consult the online list of claimed 443 rights at http://www.ietf.org/ipr. 445 The IETF takes no position regarding the validity or scope of any 446 intellectual property or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; neither does it represent that it 450 has made any effort to identify any such rights. Information on the 451 IETF's procedures with respect to rights in standards-track and 452 standards-related documentation can be found in BCP-11. Copies of 453 claims of rights made available for publication and any assurances of 454 licenses to be made available, or the result of an attempt made to 455 obtain a general license or permission for the use of such 456 proprietary rights by implementors or users of this specification can 457 be obtained from the IETF Secretariat. 459 6. Security Considerations 461 There is a risk that a detection algorithm is fooled by spoofed ACKs 462 that make genuine retransmits appear to the TCP sender as spurious 463 retransmits. When such a detection algorithm is run together with the 464 Eifel response algorithm, this could effectively disable congestion 465 control at the TCP sender. Should this become a concern, the Eifel 466 response algorithm SHOULD only be run together with detection 467 algorithms that are known to be safe against such "ACK spoofing 468 attacks". 470 For example, the safe variant of the Eifel detection algorithm 471 [RFC3522], is a reliable method to protect against this risk. 473 Acknowledgments 475 Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan 476 Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi 477 Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions 478 that contributed to this work. 480 Normative References 482 [RFC2581] Allman, M., Paxson, V. and W. Stevens, TCP Congestion 483 Control, RFC 2581, April 1999. 485 [RFC3390] Allman, M., Floyd, S. and C. Partridge, Increasing TCP's 486 Initial Window, RFC 3390, October 2002. 488 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 489 Requirement Levels, RFC 2119, March 1997. 491 [FHG03] Floyd, S., Henderson, T. and A. Gurtov, The NewReno 492 Modification to TCP's Fast Recovery Algorithm, work in 493 progress, draft-ietf-tsvwg-newreno-02.txt, November 2003. 495 [RFC2861] Handley, M., Padhye, J. and S. Floyd, TCP Congestion Window 496 Validation, RFC 2861, June 2000. 498 [RFC3522] Ludwig, R. and M. Meyer, The Eifel Detection Algorithm for 499 TCP, RFC3522, April 2003. 501 [RFC2988] Paxson, V. and M. Allman, Computing TCP's Retransmission 502 Timer, RFC 2988, November 2000. 504 [RFC793] Postel, J., Transmission Control Protocol, RFC793, 505 September 1981. 507 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, The Addition of 508 Explicit Congestion Notification (ECN) to IP, RFC 3168, 509 September 2001 511 Informative References 513 [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, Enhancing TCP's 514 Loss Recovery Using Limited Transmit, RFC 3042, 515 January 2001. 517 [AAAB04] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, 518 Early Retransmit for TCP and SCTP, work in progress, 519 draft-allman-tcp-early-rexmt-03.txt, December 2003. 521 [BA02] Blanton, E. and M. Allman, On Making TCP More Robust to 522 Packet Reordering, ACM Computer Communication Review, 523 Vol. 32, No. 1, January 2002. 525 [RFC3708] Blanton, E. and M. Allman, Using TCP Duplicate Selective 526 Acknowledgements (DSACKs) and SCTP Duplicate Transmission 527 Sequence Numbers (TSNs) to Detect Spurious Retransmissions, 528 RFC 3708, February 2004. 530 [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, 531 A Conservative SACK-based Loss Recovery Algorithm for TCP, 532 RFC3517, April 2003. 534 [EL04] Ekstr�m, H. and R. Ludwig, The Peak-Hopper: A New End-to- 535 End Retransmission Timer for Reliable Unicast Transport, In 536 Proceedings of IEEE INFOCOM 04, March 2004. 538 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A. 539 Romanow, An Extension to the Selective Acknowledgement 540 (SACK) Option for TCP, RFC 2883, July 2000. 542 [GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm 543 for TCP in a GPRS Network, In Proceedings of the European 544 Wireless Conference, February 2002. 546 [GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts 547 in TCP, In Proceedings of IEEE INFOCOM 03, April 2003. 549 [Jac88] Jacobson, V., Congestion Avoidance and Control, In 550 Proceedings of ACM SIGCOMM 88. 552 [RFC1323] Jacobson, V., Braden, R. and D. Borman, TCP Extensions for 553 High Performance, RFC 1323, May 1992. 555 [KP87] Karn, P. and C. Partridge, Improving Round-Trip Time 556 Estimates in Reliable Transport Protocols, In Proceedings 557 of ACM SIGCOMM 87. 559 [LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP 560 Robust Against Spurious Retransmissions, ACM Computer 561 Communication Review, Vol. 30, No. 1, January 2000. 563 [SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for 564 Detecting Spurious Retransmission Timeouts with TCP and 565 SCTP, work in progress, draft-ietf-tsvwg-tcp-frto-01.txt, 566 February 2004. 568 [WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, 569 Volume 2 (The Implementation), Addison Wesley, 570 January 1995. 572 [Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings 573 of ACM SIGCOMM 88. 575 Author's Address 577 Reiner Ludwig 578 Ericsson Research (EED) 579 Ericsson Allee 1 580 52134 Herzogenrath, Germany 581 Email: Reiner.Ludwig@ericsson.com 583 Andrei Gurtov 584 TeliaSonera Finland 585 P.O. Box 970, FIN-00051 Sonera 586 Helsinki, Finland 587 Email: andrei.gurtov@teliasonera.com 588 Homepage: http://www.cs.helsinki.fi/u/gurtov 590 This Internet-Draft expires in September 2004.