idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-response-06.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) == Outdated reference: A later version (-02) exists of draft-ietf-tcpm-frto-01 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Reiner Ludwig 2 INTERNET-DRAFT Ericsson Research 3 Expires: March 2004 Andrei Gurtov 4 HIIT 5 September, 2004 7 The Eifel Response Algorithm for TCP 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 Based on an appropriate detection algorithm, the Eifel response 33 algorithm provides a way for a TCP sender to respond to a detected 34 spurious timeout. It adapts the retransmission timer to avoid further 35 spurious timeouts, and can avoid - depending on the detection 36 algorithm - the often unnecessary go-back-N retransmits that would 37 otherwise be sent. In addition, the Eifel response algorithm restores 38 the congestion control state in such a way that packet bursts are 39 avoided. 41 Terminology 43 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 44 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 45 document, are to be interpreted as described in [RFC2119]. 47 We refer to the first-time transmission of an octet as the 'original 48 transmit'. A subsequent transmission of the same octet is referred to 49 as a 'retransmit'. In most cases this terminology can likewise be 50 applied to data segments as opposed to octets. However, when 51 repacketization occurs, a segment can contain both first-time 52 transmissions and retransmissions of octets. In that case, this 53 terminology is only consistent when applied to octets. For the Eifel 54 detection and response algorithms this makes no difference as they 55 also operate correctly when repacketization occurs. 57 We use the term 'acceptable ACK' as defined in [RFC793]. That is an 58 ACK that acknowledges previously unacknowledged data. We use the term 59 'bytes_acked' to refer to the amount (in terms of octets) of 60 previously unacknowledged data that is acknowledged by the most 61 recently received acceptable ACK. We use the TCP sender state 62 variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA 63 holds the segment sequence number of the oldest outstanding segment. 64 SND.NXT holds the segment sequence number of the next segment the TCP 65 sender will (re-)transmit. In addition, we define as 'SND.MAX' the 66 segment sequence number of the next original transmit to be sent. The 67 definition of SND.MAX is equivalent to the definition of 'snd_max' in 68 [WS95]. 70 We use the TCP sender state variables 'cwnd' (congestion window), and 71 'ssthresh' (slow-start threshold), and the term 'FlightSize' as 72 defined in [RFC2581]. We use the term 'Initial Window (IW)' as 73 defined in [RFC3390]. FlightSize is the amount (in terms of octets) 74 of outstanding data at a given point in time. The IW is the size of 75 the sender's congestion window after the three-way handshake is 76 completed. We use the TCP sender state variables 'SRTT' and 'RTTVAR', 77 and the terms 'RTO' and 'G' as defined in [RFC2988]. G is the clock 78 granularity of the retransmission timer. In addition, we assume that 79 the TCP sender maintains in the (local) variable 'RTT-SAMPLE' the 80 value of the latest round-trip time (RTT) measurement. 82 We use the TCP sender state variable 'T_last', and the term 'tcpnow' 83 as used in [RFC2861]. T_last holds the time when the TCP sender sent 84 the last data segment while tcpnow is the TCP sender's current 85 "system time". 87 1. Introduction 89 The Eifel response algorithm relies on a detection algorithm such as 90 the Eifel detection algorithm defined in [RFC3522]. That document 91 contains informative background and motivation context that may be 92 useful for implementers of the Eifel response algorithm, but it is 93 not necessary to read [RFC3522] in order to implement the Eifel 94 response algorithm. Note that alternative response algorithms have 95 been 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. Appropriate 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 a standards track or experimental 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, and that sets the variable 164 SpuriousRecovery as outlined in Section 2. In case 165 [RFC3522] is used as the detection algorithm, steps (1) - 166 (6) of that algorithm go here. 168 (7) If SpuriousRecovery equals SPUR_TO, then 169 proceed to step (8), 171 else if SpuriousRecovery equals LATE_SPUR_TO, then 172 proceed to step (9), 174 else 175 proceed to step (DONE). 177 (8) Resume the transmission with previously unsent data: 179 Set 180 SND.NXT <- SND.MAX 182 (9) Reversing the congestion control state: 184 If the acceptable ACK has the ECN-Echo flag [RFC3168] set, 185 then 186 proceed to step (DONE), 188 else set 189 cwnd <- FlightSize + min (bytes_acked, IW) 190 ssthresh <- pipe_prev 192 Proceed to step (DONE). 194 (10) Interworking with Congestion Window Validation: 196 If congestion window validation is implemented according 197 to [RFC2861], then set 198 T_last <- tcpnow 200 (11) Adapt the Conservativeness of the Retransmission Timer: 202 Upon the first RTT-SAMPLE taken from new data, i.e., the 203 first RTT-SAMPLE that can be derived from an acceptable 204 ACK for data that was previously unsent when the spurious 205 timeout occurred, 207 if the retransmission timer is implemented according 208 to [RFC2988], then set 209 SRTT <- max (SRTT_prev, RTT-SAMPLE) 210 RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2) 211 RTO <- SRTT + max (G, 4*RTTVAR) 213 Run the bounds check on the RTO (rules (2.4) and 214 (2.5) in [RFC2988]), and restart the 215 retransmission timer, 217 else 218 Appropriately adapt the conservativeness of the 219 retransmission timer that is implemented. 221 (DONE) No further processing. 223 3.2 Storing the Current Congestion Control State (step 0) 225 The TCP sender stores in pipe_prev what is considered a safe slow- 226 start threshold (ssthresh) before loss recovery is initiated, i.e., 227 before the loss indication is taken into account. This is either the 228 current FlightSize if the TCP sender is in congestion avoidance or 229 the current ssthresh if the TCP sender is in slow-start. If the TCP 230 sender later detects that it has entered loss recovery unnecessarily, 231 then pipe_prev is used in step (9) to reverse the congestion control 232 state. Thus, until the loss recovery phase is terminated, pipe_prev 233 maintains a memory of the congestion control state of the time right 234 before the loss recovery phase was initiated. A similar approach is 235 proposed in [RFC2861], where this state is stored in ssthresh 236 directly after a TCP sender has become idle or application-limited. 238 There had been debates about whether the value of pipe_prev should be 239 decayed over time, e.g., upon subsequent timeouts for the same 240 outstanding segment. We do not require the decaying of pipe_prev for 241 the Eifel response algorithm, and do not believe that such a 242 conservative approach should be in place. Instead, we follow the idea 243 of revalidating the congestion window through slow-start as suggested 244 in [RFC2861]. That is, in step (9), the cwnd is reset to a value that 245 avoids large packet bursts, while ssthresh is reset to the value of 246 pipe_prev. Note that [RFC2581] and [RFC2861] also do not require a 247 decaying of ssthresh after it has been reset in response to a loss 248 indication, or after a TCP sender has become idle or application- 249 limited. 251 3.3 Suppressing the Unnecessary go-back-N Retransmits (step 8) 253 Without the use of the TCP timestamps option [RFC1323], the TCP 254 sender suffers from the retransmission ambiguity problem [Zh86], 255 [KP87]. Hence, when the first acceptable ACK arrives after a spurious 256 timeout, the TCP sender must assume that this ACK was sent in 257 response to the retransmit when in fact it was sent in response to an 258 original transmit. Furthermore, the TCP sender must further assume 259 that all other segments outstanding at that point were lost. 261 Note: Except for certain cases where original ACKs were lost, the 262 first acceptable ACK cannot carry a DSACK option [RFC2883]. 264 Consequently, once the TCP sender's state has been updated after the 265 first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is 266 what causes the often unnecessary go-back-N retransmits. From that 267 point on every arriving acceptable ACK that was sent in response to 268 an original transmit will advance SND.NXT. But as long as SND.NXT is 269 smaller than the value that SND.MAX had when the timeout occurred, 270 those ACKs will clock out retransmits, whether those segments were 271 lost or not. 273 In fact, during this phase the TCP sender breaks 'packet 274 conservation' [Jac88]. This is because the go-back-N retransmits are 275 sent during slow-start. I.e., for each original transmit leaving the 276 network, two retransmits are sent into the network as long as SND.NXT 277 does not equal SND.MAX (see [LK00] for more detail). 279 Once a spurious timeout has been detected (based upon receiving an 280 ACK for an original transmit), it is therefore safe to let the TCP 281 sender resume the transmission with previously unsent data. Thus, the 282 Eifel response algorithm changes the TCP sender's state by setting 283 SND.NXT to SND.MAX in that case. Note that this step is only executed 284 if the variable SpuriousRecovery equals SPUR_TO, which in turn 285 requires a detection algorithm such as the Eifel detection algorithm 286 [RFC3522] or the F-RTO algorithm [SK04] that detects a spurious 287 retransmit based upon receiving an ACK for an original transmit (as 288 opposed to the ACK for the retransmit [RFC3708]). 290 3.4 Reversing the Congestion Control State (step 9) 292 When a TCP sender enters loss recovery, it also assumes that is has 293 received a congestion indication. In response to that it reduces 294 cwnd, and ssthresh. However, once the TCP sender detects that the 295 loss recovery has been falsely triggered, this reduction was 296 unnecessary. In fact, no congestion indication has been received. We 297 therefore believe that it is safe to revert to the previous 298 congestion control state following the approach of revalidating the 299 congestion window as outlined below. This is unless the acceptable 300 ACK signals congestion through the ECN-Echo flag [RFC3168]. In that 301 case, the TCP sender MUST refrain from reversing congestion control 302 state. 304 If the ECN-Echo flag is not set, cwnd is reset to the sum of the 305 current FlightSize and the minimum of bytes_acked and IW. Recall that 306 bytes_acked is the number of bytes that have been acknowledged by the 307 acceptable ACK. Note that the value of cwnd must not be changed any 308 further for that ACK, and that the value of FlightSize at this point 309 in time may be different from the value of FlightSize in step (0). 310 The value of IW puts a limit on the size of the packet burst that the 311 TCP sender may send into the network after the Eifel response 312 algorithm has terminated. The value of IW is considered an acceptable 313 burst size. It is the amount of data that a TCP sender may send into 314 a yet "unprobed" network at the beginning of a connection. 316 Then ssthresh is reset to the value of pipe_prev. As a result, the 317 TCP sender either immediately resumes probing the network for more 318 bandwidth in congestion avoidance, or it first slow-starts to what is 319 considered a safe operating point for the congestion window. In some 320 cases, this can mean that the first few acceptable ACKs that arrive 321 will not clock out any data segments. 323 3.5 Interworking with the CWV Algorithm (step 10) 325 An implementation of the Congestion Window Validation (CWV) algorithm 326 [RFC2861] could potentially misinterpret a delay spike that caused a 327 spurious timeout as a phase where the TCP sender had been idle. 328 Therefore, T_last is reset to prevent the triggering of the CWV 329 algorithm in this case. 331 Note: The term 'idle' implies that the TCP sender has no data 332 outstanding, i.e., all data sent has been acknowledged [Jac88]. 333 According to this definition, a TCP sender is not idle while it is 334 waiting for an acceptable ACK after a timeout. Unfortunately, the 335 pseudo-code in [RFC2861] does not include a check for the 336 condition "idle" (SND.UNA == SND.MAX). We therefore had to add 337 step (10) to the Eifel response algorithm. 339 3.6 Adapting the Retransmission Timer (step 11) 341 There is currently only one retransmission timer standardized for TCP 342 [RFC2988]. We therefore only address that timer explicitly. Future 343 standards that might define alternatives to [RFC2988] should propose 344 similar measures to adapt the conservativeness of the retransmission 345 timer. 347 A spurious timeout often results from a delay spike, which is a 348 sudden increase of the RTT that usually cannot be predicted. After a 349 delay spike the RTT may have changed permanently, e.g., due to a path 350 change, or because the available bandwidth on a bandwidth-dominated 351 path has decreased. This may often occur with wide-area wireless 352 access links. In this case, the RTT estimators (SRTT and RTTVAR) 353 should be reinitialized from the first RTT-SAMPLE taken from new data 354 according to rule (2.2) of [RFC2988]. That is, from the first RTT- 355 SAMPLE that can be derived from an acceptable ACK for data that was 356 previously unsent when the spurious timeout occurred. 358 However, a delay spike may only indicate a transient phase, after 359 which the RTT returns to its previous range of values, or even to 360 smaller values. Also, a spurious timeout may occur because the TCP 361 sender's RTT estimators were only inaccurate, so that the 362 retransmission timer expires "a tad too early". We believe that two 363 times the clock granularity of the retransmission timer (2 * G) is a 364 reasonable upper bound on "a tad too early". Thus, when the new RTO 365 is calculated in step (11) we ensure that it is at least (2 * G) 366 greater (see also step (0)) than the RTO was before the spurious 367 timeout occurred. 369 Note that other TCP sender processing will usually take place between 370 steps (10) and (11). During this phase, i.e., before step (11) has 371 been reached, the RTO is managed according to the rules of [RFC2988]. 372 We believe that this is sufficiently conservative for the following 373 reasons. First, the retransmission timer is restarted upon the 374 acceptable ACK that was used to detect the spurious timeout. As a 375 result, the delay spike is already implicitly factored in for 376 segments outstanding at that time. This is discussed in more in 377 detail in [EL04] where this effect is called the "RTO offset". 378 Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE 379 can be derived from that acceptable ACK. This RTT-SAMPLE must be 380 relatively large since it includes the delay spike that caused the 381 spurious timeout. Consequently, the RTT estimators will be updated 382 rather conservatively. Without timestamps the RTO will stay 383 conservatively backed-off due to Karn's algorithm [RFC2988] until the 384 first RTT-SAMPLE that can be derived from an acceptable ACK for data 385 that was previously unsent when the spurious timeout occurred. 387 To have the new RTO become effective, the retransmission timer needs 388 to be restarted. This is consistent with [RFC2988] which recommends 389 restarting the retransmission timer with the arrival of an acceptable 390 ACK. 392 4. Advanced Loss Recovery is Crucial for the Eifel Response Algorithm 393 We have studied environments where spurious timeouts and multiple 394 losses from the same flight of packets often coincide [GL02], [GL03]. 395 In such a case the oldest outstanding segment does arrive at the TCP 396 receiver, but one or more packets from the remaining outstanding 397 flight are lost. In those environments, TCP-Reno's performance 398 suffers if the Eifel response algorithm is operated without an 399 advanced loss recovery scheme such as a SACK-based scheme [RFC3517] 400 or NewReno [FHG03]. The reason is TCP-Reno's aggressiveness after a 401 spurious timeout. Even though it breaks 'packet conservation' (see 402 Section 3.3) when blindly retransmitting all outstanding segments, it 403 usually recovers all packets lost from that flight within a single 404 round-trip time. On the contrary, the more conservative 405 TCP-Reno-with-Eifel is often forced into another timeout. Thus, we 406 recommend to always operate the Eifel response algorithm in 407 combination with [RFC3517] or [FHG03]. Additional robustness to 408 multiple losses from the same flight is achieved with the Limited 409 Transmit and Early Retransmit algorithms [RFC3042], [AAAB04]. 411 Note: The SACK-based scheme we used for our simulations in [GL02] 412 and [GL03] is different from the SACK-based scheme that later got 413 standardized [RFC3517]. The key difference is that [RFC3517] is 414 more robust to multiple losses from the same flight. It is less 415 conservative in declaring that a packet has left the network, and 416 is therefore less dependent on timeouts to recover genuine packet 417 losses. 419 In case the NewReno algorithm [FHG03] is used in combination with the 420 Eifel response algorithm, step 1) of the NewReno algorithm SHOULD be 421 modified as follows, but only if SpuriousRecovery equals SPUR_TO: 423 1) Three duplicate ACKs: 424 When the third duplicate ACK is received and the sender is not 425 already in the Fast Recovery procedure, go to Step 1A. 427 That is, the entire step 1B) of the NewReno algorithm is obsolete 428 because step (8) of the Eifel response algorithm avoids the case 429 where three duplicate ACKs result from unnecessary go-back-N 430 retransmits after a timeout. Step (8) of the Eifel response algorithm 431 avoids such unnecessary go-back-N retransmits in the first place. 432 However, recall that step (8) is only executed if the variable 433 SpuriousRecovery equals SPUR_TO, which in turn requires a detection 434 algorithm such as the Eifel detection algorithm [RFC3522] or the 435 F-RTO algorithm [SK04] that detects a spurious retransmit based upon 436 receiving an ACK for an original transmit (as opposed to the ACK for 437 the retransmit [RFC3708]). 439 5. IPR Considerations 441 The IETF has been notified of intellectual property rights claimed in 442 regard to some or all of the specification contained in this 443 document. For more information consult the online list of claimed 444 rights at http://www.ietf.org/ipr. 446 The IETF takes no position regarding the validity or scope of any 447 intellectual property or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; neither does it represent that it 451 has made any effort to identify any such rights. Information on the 452 IETF's procedures with respect to rights in standards-track and 453 standards-related documentation can be found in BCP-11. Copies of 454 claims of rights made available for publication and any assurances of 455 licenses to be made available, or the result of an attempt made to 456 obtain a general license or permission for the use of such 457 proprietary rights by implementors or users of this specification can 458 be obtained from the IETF Secretariat. 460 6. Security Considerations 462 There is a risk that a detection algorithm is fooled by spoofed ACKs 463 that make genuine retransmits appear to the TCP sender as spurious 464 retransmits. When such a detection algorithm is run together with the 465 Eifel response algorithm, this could effectively disable congestion 466 control at the TCP sender. Should this become a concern, the Eifel 467 response algorithm SHOULD only be run together with detection 468 algorithms that are known to be safe against such "ACK spoofing 469 attacks". 471 For example, the safe variant of the Eifel detection algorithm 472 [RFC3522], is a reliable method to protect against this risk. 474 Acknowledgments 476 Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan 477 Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi 478 Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions 479 that contributed to this work. 481 Normative References 483 [RFC2581] Allman, M., Paxson, V. and W. Stevens, TCP Congestion 484 Control, RFC 2581, April 1999. 486 [RFC3390] Allman, M., Floyd, S. and C. Partridge, Increasing TCP's 487 Initial Window, RFC 3390, October 2002. 489 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 490 Requirement Levels, RFC 2119, March 1997. 492 [FHG03] Floyd, S., Henderson, T. and A. Gurtov, The NewReno 493 Modification to TCP's Fast Recovery Algorithm, work in 494 progress, draft-ietf-tsvwg-newreno-02.txt, November 2003. 496 [RFC2861] Handley, M., Padhye, J. and S. Floyd, TCP Congestion Window 497 Validation, RFC 2861, June 2000. 499 [RFC3522] Ludwig, R. and M. Meyer, The Eifel Detection Algorithm for 500 TCP, RFC3522, April 2003. 502 [RFC2988] Paxson, V. and M. Allman, Computing TCP's Retransmission 503 Timer, RFC 2988, November 2000. 505 [RFC793] Postel, J., Transmission Control Protocol, RFC793, 506 September 1981. 508 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, The Addition of 509 Explicit Congestion Notification (ECN) to IP, RFC 3168, 510 September 2001 512 Informative References 514 [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, Enhancing TCP's 515 Loss Recovery Using Limited Transmit, RFC 3042, 516 January 2001. 518 [AAAB04] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, 519 Early Retransmit for TCP and SCTP, work in progress, 520 draft-allman-tcp-early-rexmt-03.txt, December 2003. 522 [BA02] Blanton, E. and M. Allman, On Making TCP More Robust to 523 Packet Reordering, ACM Computer Communication Review, 524 Vol. 32, No. 1, January 2002. 526 [RFC3708] Blanton, E. and M. Allman, Using TCP Duplicate Selective 527 Acknowledgements (DSACKs) and SCTP Duplicate Transmission 528 Sequence Numbers (TSNs) to Detect Spurious Retransmissions, 529 RFC 3708, February 2004. 531 [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, 532 A Conservative SACK-based Loss Recovery Algorithm for TCP, 533 RFC3517, April 2003. 535 [EL04] Ekstr�m, H. and R. Ludwig, The Peak-Hopper: A New End-to- 536 End Retransmission Timer for Reliable Unicast Transport, In 537 Proceedings of IEEE INFOCOM 04, March 2004. 539 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A. 540 Romanow, An Extension to the Selective Acknowledgement 541 (SACK) Option for TCP, RFC 2883, July 2000. 543 [GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm 544 for TCP in a GPRS Network, In Proceedings of the European 545 Wireless Conference, February 2002. 547 [GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts 548 in TCP, In Proceedings of IEEE INFOCOM 03, April 2003. 550 [Jac88] Jacobson, V., Congestion Avoidance and Control, In 551 Proceedings of ACM SIGCOMM 88. 553 [RFC1323] Jacobson, V., Braden, R. and D. Borman, TCP Extensions for 554 High Performance, RFC 1323, May 1992. 556 [KP87] Karn, P. and C. Partridge, Improving Round-Trip Time 557 Estimates in Reliable Transport Protocols, In Proceedings 558 of ACM SIGCOMM 87. 560 [LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP 561 Robust Against Spurious Retransmissions, ACM Computer 562 Communication Review, Vol. 30, No. 1, January 2000. 564 [SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for 565 Detecting Spurious Retransmission Timeouts with TCP and 566 SCTP, work in progress, draft-ietf-tcpm-frto-01.txt, 567 July 2004. 569 [WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, 570 Volume 2 (The Implementation), Addison Wesley, 571 January 1995. 573 [Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings 574 of ACM SIGCOMM 88. 576 Author's Address 578 Reiner Ludwig 579 Ericsson Research (EED) 580 Ericsson Allee 1 581 52134 Herzogenrath, Germany 582 Email: Reiner.Ludwig@ericsson.com 584 Andrei Gurtov 585 Helsinki Institute for Information Technology (HIIT) 586 P.O. Box 9800, FIN-02015 587 HUT, Finland 588 Email: andrei.gurtov@cs.helsinki.fi 589 Homepage: http://www.cs.helsinki.fi/u/gurtov 591 This Internet-Draft expires in March 2005.