idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-response-04.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 4) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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 ([RFC2581], [WS95], [RFC793], [RFC2119], [RFC2988]), 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 2582 (Obsoleted by RFC 3782) ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** 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) -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) == Outdated reference: A later version (-01) exists of draft-ietf-tsvwg-tcp-frto-00 Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: April 2004 Andrei Gurtov 5 TeliaSonera 6 October, 2003 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 TCP 60 sender state variables 'SND.UNA' and 'SND.NXT' as defined in 61 [RFC793]. SND.UNA holds the segment sequence number of the oldest 62 outstanding segment. SND.NXT holds the segment sequence number of the 63 next segment the TCP sender will (re-)transmit. In addition, we 64 define as 'SND.MAX' the segment sequence number of the next original 65 transmit to be sent. The definition of SND.MAX is equivalent to the 66 definition of 'snd_max' in [WS95]. 68 We use the TCP sender state variables 'cwnd' (congestion window), and 69 'ssthresh' (slow-start threshold), and the terms 'FlightSize', and 70 'Initial Window (IW)' as defined in [RFC2581]. FlightSize is the 71 amount of outstanding data at a given point in time. The IW is the 72 size of the sender's congestion window after the three-way handshake 73 is completed. We use the TCP sender state variables 'SRTT' and 74 'RTTVAR', and the term 'RTO' as defined in [RFC2988]. In addition, we 75 assume that the TCP sender maintains in the variable 'RTT-SAMPLE' the 76 value of the latest round-trip time (RTT) measurement. 78 1. Introduction 80 The Eifel response algorithm relies on a detection algorithm such as 81 the Eifel detection algorithm defined in [RFC3522]. That document 82 discusses the relevant background and motivation that also applies to 83 this document. Hence, the reader is expected to be familiar with 84 [RFC3522]. Note that alternative response algorithms have been 85 proposed [BA02] that could also rely on the Eifel detection 86 algorithm, and vice versa alternative detection algorithms have been 87 proposed [BA03], [SK03] that could work together with the Eifel 88 response algorithm. 90 Based on an appropriate detection algorithm, the Eifel response 91 algorithm provides a way for a TCP sender to respond to a detected 92 spurious timeout. It adapts the retransmission timer to avoid further 93 spurious timeouts, and can avoid - depending on the detection 94 algorithm - the often unnecessary go-back-N retransmits that would 95 otherwise be sent. In addition, the Eifel response algorithm restores 96 the congestion control state in such a way that packet bursts are 97 avoided. 99 Note: A previous version of the Eifel Response algorithm also 100 included a response to a detected spurious fast retransmit. 101 However, since a consensus was not reached about how to adapt the 102 duplicate acknowledgement threshold in that case, that part of the 103 algorithm was removed for the time being. 105 2. Interworking with Detection Algorithms 107 If the Eifel response algorithm is implemented at the TCP sender, it 108 MUST be implemented together with a detection algorithm that is 109 specified in an RFC. 111 Designers of detection algorithms who want their algorithms to work 112 together with the Eifel response algorithm should reuse the variable 113 SpuriousRecovery with the semantics and defined values as specified 114 in [RFC3522]. In addition, we define LATE_SPUR_TO (equal -1) as 115 another possible value of the variable SpuriousRecovery. Detection 116 algorithms should set the value of SpuriousRecovery to LATE_SPUR_TO 117 if the detection of a spurious retransmit is based upon receiving the 118 ACK for the retransmit (as opposed to the ACK for the original 119 transmit). For example, this applies to detection algorithms that are 120 based on the DSACK option [BA03]. 122 3. The Eifel Response Algorithm 124 The complete algorithm is specified in section 3.1. In sections 3.2 125 to 3.5, we motivate the different steps of the algorithm. 127 3.1. The Algorithm 129 Given that a TCP sender has enabled a detection algorithm that 130 complies with the requirements set in Section 2, a TCP sender MAY use 131 the Eifel response algorithm as defined in this subsection. 133 If the Eifel response algorithm is used, the following steps MUST be 134 taken by the TCP sender, but only upon initiation of loss recovery, 135 i.e., when the timeout-based retransmit is sent. Note: The algorithm 136 MUST NOT be reinitiated after loss recovery has already started. In 137 particular, it may not be reinitiated upon subsequent timeouts for 138 the same segment, and not upon retransmitting segments other than the 139 oldest outstanding segment. 141 (INIT) Before the variables cwnd and ssthresh get updated when 142 loss recovery is initiated, set a "pipe_prev" variable as 143 follows: 145 pipe_prev <- max (FlightSize, ssthresh) 147 (DET) This is a placeholder for a detection algorithm that must 148 be executed at this point. In case [RFC3522] is used as 149 the detection algorithm, steps (1) - (6) of that algorithm 150 go here. 152 (RESP) If SpuriousRecovery equals SPUR_TO, then 153 proceed to step (STO.1), 155 else if SpuriousRecovery equals LATE_SPUR_TO, then 156 proceed to step (STO.2), 158 else 159 proceed to step (DONE). 161 (STO.1) Resume transmission off the top: 163 Set 164 SND.NXT <- SND.MAX 166 (STO.2) Adapt the Conservativeness of the Retransmission Timer: 168 If the retransmission timer is implemented according to 169 [RFC2988], then 170 if the TCP Timestamps option [RFC1323] is enabled for 171 this connection, then set 172 SRTT <- RTT-SAMPLE 173 RTTVAR <- RTT-SAMPLE/2 175 else set 176 RTTVAR <- max (2 * RTTVAR, SRTT) 177 SRTT <- 2 * SRTT 179 Set 180 RTO <- SRTT + max (G, 4*RTTVAR) 181 Restart the retransmission timer 183 else 184 appropriately adapt the conservativeness of the 185 retransmission timer that is implemented. 187 Proceed to step (ReCC). 189 (ReCC) Reversing the congestion control state: 191 If the acceptable ACK has the ECN-Echo flag [RFC3168] set, 192 then 193 proceed to step (DONE), 195 else set 196 cwnd <- FlightSize + min (bytes_acked, IW) 197 ssthresh <- pipe_prev 199 Proceed to step (DONE). 201 (CWV) Interworking with Congestion Window Validation (the 202 variables 'T_last' and 'tcpnow' are defined in [RFC2861]): 204 If congestion window validation is implemented according 205 to [RFC2861], then set 206 T_last <- tcpnow 208 (DONE) No further processing. 210 3.2 Storing the Current Congestion Control State (step INIT) 212 The TCP sender stores in pipe_prev what is considered a "safe" slow- 213 start threshold (ssthresh) before loss recovery is initiated, i.e., 214 before the loss indication is taken into account. This is either the 215 current FlightSize if the TCP sender is in congestion avoidance or 216 the current ssthresh if the TCP sender is in slow-start. If the TCP 217 sender later detects that it has entered loss recovery unnecessarily, 218 then pipe_prev is used in step (ReCC) to reverse the congestion 219 control state. Thus, until the loss recovery phase is terminated, 220 pipe_prev maintains a memory of the congestion control state of the 221 time right before the loss recovery phase was initiated. A similar 222 approach is proposed in [RFC2861], where this state is stored in 223 ssthresh directly after a TCP sender has become application-limited. 225 There had been debates about whether the value of pipe_prev should be 226 decayed over time, e.g., upon subsequent timeouts for the same 227 outstanding segment. We do not require the decaying of pipe_prev for 228 the Eifel response algorithm, and do not believe that such a 229 conservative approach would be in place. Instead, we follow the idea 230 of revalidating the congestion window through slow-start as suggested 231 in [RFC2861]. That is, in step (ReCC), the cwnd is reset to a value 232 that avoids large packet bursts, while ssthresh is reset to the value 233 of pipe_prev. Note that [RFC2581] and [RFC2861] also do not require a 234 decaying of ssthresh after it has been reset in response to a loss 235 indication, or after a TCP sender has become application-limited. 237 3.3 Responding to Spurious Timeouts 239 3.3.1 Suppressing the Unnecessary go-back-N Retransmits (step STO.1) 241 Without the use of the TCP timestamps option, the TCP sender suffers 242 from the retransmission ambiguity problem [Zh86], [KP87]. Hence, when 243 the first acceptable ACK arrives after a spurious timeout, the TCP 244 sender must assume that this ACK was sent in response to the 245 retransmit when in fact it was sent in response to the original 246 transmit. Furthermore, the TCP sender must further assume that all 247 other segments outstanding at that point were lost. 249 Note: Except for certain cases where original ACKs were lost, the 250 first acceptable ACK cannot carry any DSACK option [RFC2883]. 252 Consequently, once the TCP sender's state has been updated after the 253 first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is 254 what causes the often unnecessary go-back-N retransmits. From that 255 point on every arriving acceptable ACK that was sent in response to 256 an original transmit will advance SND.NXT. But as long as SND.NXT is 257 smaller than the value that SND.MAX had when the timeout occurred, 258 those ACKs will clock out retransmits, whether those segments were 259 lost or not. 261 In fact, during this phase the TCP sender breaks 'packet 262 conservation' [Jac88]. This is because the go-back-N retransmits are 263 sent during slow-start. I.e., for each original transmit leaving the 264 network, two retransmits are sent into the network as long as SND.NXT 265 does not equal SND.MAX (see [LK00] for more detail). 267 The use of the TCP timestamps option reliably eliminates the 268 retransmission ambiguity problem. Once the Eifel detection algorithm 269 has detected that a timeout was spurious, it is therefore safe to let 270 the TCP sender resume the transmission with new data. Thus, the Eifel 271 response algorithm changes the TCP sender's state by setting SND.NXT 272 to SND.MAX in that case. 274 3.3.2 Adapting the Retransmission Timer (step STO.2) 276 There is currently only one retransmission timer standardized for TCP 277 [RFC2988]. We therefore only address that timer explicitly. Future 278 standards that might define alternatives to [RFC2988] should propose 279 similar measures to adapt the conservativeness of the retransmission 280 timer. 282 Since the timeout was spurious, the TCP sender's RTT estimators are 283 likely to be off. If timestamps are enabled for this connection, a 284 new and valid RTT measurement (RTT-SAMPLE) can be derived from the 285 acceptable ACK. It is therefore suggested to reinitialize the RTT 286 estimators from RTT-SAMPLE according to rule (2.2) of RFC2988. Note 287 that this RTT-SAMPLE will be relatively large since it will include 288 the delay spike that caused the spurious timeout in the first place. 289 If timestamps are not enabled for this connection, the TCP sender 290 should instead double SRTT and also make RTTVAR more conservative. 292 To have the new RTO become effective, the retransmission timer needs 293 to be restarted. This is consistent with [RFC2988] which recommends 294 restarting the retransmission timer with the arrival of an acceptable 295 ACK. 297 3.4 Reversing the Congestion Control State (step ReCC) 299 When a TCP sender enters loss recovery, it also assumes that is has 300 received a congestion indication. In response to that it reduces 301 cwnd, and ssthresh. However, once the TCP sender detects that the 302 loss recovery has been falsely triggered, this reduction was 303 unnecessary. In fact, no congestion indication has been received. We 304 therefore believe that it is safe to revert to the previous 305 congestion control state following the approach of revalidating the 306 congestion window as outlined below. This is unless the acceptable 307 ACK signals congestion through the ECN-Echo flag [RFC3168]. In that 308 case, the TCP sender MUST refrain from reversing congestion control 309 state. 311 If the ECN-Echo flag is not set, cwnd is reset to the sum of the 312 current FlightSize and the minimum of IW and the number of bytes that 313 have been acknowledged by the acceptable ACK. Note that the value of 314 cwnd must not be changed any further for that ACK, and that the value 315 of FlightSize at this point in time may be different from the value 316 of FlightSize in step (INIT). The value of IW puts a limit on the 317 size of the packet burst that the TCP sender may send into the 318 network after the Eifel response algorithm has terminated. The value 319 of IW is considered an acceptable burst size. It is the amount of 320 data that a TCP sender may send into a yet "unprobed" network at the 321 beginning of a connection. 323 The TCP sender is then forced into slow-start by resetting ssthresh 324 to the value of pipe_prev. As a result, the TCP sender either 325 immediately resumes probing the network for more bandwidth in 326 congestion avoidance, or it first slow-starts to what is considered a 327 "safe" operating point for the congestion window. In some cases, this 328 can mean that the first few acceptable ACKs that arrive will not 329 clock out any data segments. 331 3.5 Interworking with the Congestion Window Validation Algorithm 333 An implementation of the Congestion Window Validation (CWV) algorithm 334 [RFC2861] could potentially misinterpret a delay spike that caused a 335 spurious timeout as a phase where the TCP sender had been 336 application-limited. To prevent the triggering of CWV algorithm in 337 this case, the variable 'T_last' defined in [RFC2861] is reset. 339 4. Non-Conservative Advanced Loss Recovery after Spurious Timeouts 341 A TCP sender MAY implement an optimistic form of advanced loss 342 recovery after a spurious timeout has been detected as motivated in 343 this section. Such a scheme MUST be terminated after the highest 344 sequence number outstanding when the spurious timeout was detected 345 has been acknowledged. 347 We have studied environments where spurious timeouts and multiple 348 losses from the same flight of packets often coincide [GL02]. In such 349 a case the oldest outstanding segment does arrive at the TCP 350 receiver, but one or more packets from the remaining outstanding 351 flight are lost. In those environments, TCP-Reno's performance 352 suffers if the Eifel response algorithm is operated without an 353 advanced loss recovery scheme such as NewReno [RFC2582], or SACK- 354 based schemes [RFC2018], [RFC3517]. The reason is TCP-Reno's 355 aggressiveness after a spurious timeout. Even though it breaks 356 'packet conservation' (see Section 2.2.1) when blindly retransmitting 357 all outstanding segments, it usually recovers all packets lost from 358 that flight within a single round-trip time. On the contrary, the 359 more conservative TCP-Reno/Eifel is often forced into another 360 (backed-off) timeout. 362 However, in a more recent study [GL03], we found that the mentioned 363 advanced loss recovery schemes are often too conservative to compete 364 against TCP-Reno's blind go-back-N in terms of quickly recovering 365 multiple losses after a spurious timeout. The problem with the 366 NewReno scheme is that it does not exploit knowledge (e.g., provided 367 through SACK options) about which segments were lost. The problem 368 with the conservative SACK-based scheme [RFC3517] is that it waits 369 for three SACKs before it retransmits a lost segment. This may often 370 lead to a second - and in this case genuine - (potentially backed- 371 off) timeout. In those cases TCP-Reno's loss recovery is often 372 quicker due the blind go-back-N. This could be viewed as a 373 disincentive to the deployment of the Eifel response algorithm. 375 We therefore suggest that a TCP sender MAY implement an optimistic 376 (non-conservative) form of advanced loss recovery after a spurious 377 timeout has been detected, if the following guidelines are met: 379 - Packet Conservation: The TCP sender may not have more segments 380 (counting both original transmits and retransmits) in flight 381 than indicated by the congestion window. 383 - A retransmit may only be sent when a potential loss has been 384 indicated. For example, a single duplicate ACK is such an 385 indication; potentially with the corresponding SACK info in case 386 the SACK option is enabled for the connection. 388 We have developed and evaluated such a scheme (a variant of NewReno 389 that exploits SACK info) in [GL03] that shows good results. 391 5. IPR Considerations 393 The IETF has been notified of intellectual property rights claimed in 394 regard to some or all of the specification contained in this 395 document. For more information consult the online list of claimed 396 rights at http://www.ietf.org/ipr. 398 The IETF takes no position regarding the validity or scope of any 399 intellectual property or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; neither does it represent that it 403 has made any effort to identify any such rights. Information on the 404 IETF's procedures with respect to rights in standards-track and 405 standards-related documentation can be found in BCP-11. Copies of 406 claims of rights made available for publication and any assurances of 407 licenses to be made available, or the result of an attempt made to 408 obtain a general license or permission for the use of such 409 proprietary rights by implementors or users of this specification can 410 be obtained from the IETF Secretariat. 412 6. Security Considerations 414 There is a risk that a detection algorithm is fooled by spoofed ACKs 415 that make genuine retransmits appear to the TCP sender as spurious 416 retransmits. When such a detection algorithm is run together with the 417 Eifel response algorithm, this could effectively disable congestion 418 control at the TCP sender. Should this become a concern, the Eifel 419 response algorithm SHOULD only be run together with detection 420 algorithms that are known to be safe against such "ACK spoofing 421 attacks". 423 For example, the safe variant of the Eifel detection algorithm 424 [RFC3522], is a reliable method to protect against this risk. 426 Acknowledgments 428 Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan 429 Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi 430 Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions 431 that contributed to this work. 433 Normative References 435 [RFC2581] Allman, M., Paxson, V. and W. Stevens, TCP Congestion 436 Control, RFC 2581, April 1999. 438 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 439 Requirement Levels, RFC 2119, March 1997. 441 [RFC2582] Floyd, S. and T. Henderson, The NewReno Modification to 442 TCP's Fast Recovery Algorithm, RFC 2582, April 1999. 444 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A. 445 Romanow, An Extension to the Selective Acknowledgement 446 (SACK) Option for TCP, RFC 2883, July 2000. 448 [RFC2861] Handley, M., Padhye, J. and S. Floyd, TCP Congestion Window 449 Validation, RFC 2861, June 2000. 451 [RFC1323] Jacobson, V., Braden, R. and D. Borman, TCP Extensions for 452 High Performance, RFC 1323, May 1992. 454 [RFC3522] Ludwig, R. and M. Meyer, The Eifel Detection Algorithm for 455 TCP, RFC3522, April 2003. 457 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, TCP 458 Selective Acknowledgement Options, RFC 2018, October 1996. 460 [RFC2988] Paxson, V. and M. Allman, Computing TCP's Retransmission 461 Timer, RFC 2988, November 2000. 463 [RFC793] Postel, J., Transmission Control Protocol, RFC793, 464 September 1981. 466 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, The Addition of 467 Explicit Congestion Notification (ECN) to IP, RFC 3168, 468 September 2001 470 Informative References 472 [BA02] Blanton, E. and M. Allman, On Making TCP More Robust to 473 Packet Reordering, ACM Computer Communication Review, 474 Vol. 32, No. 1, January 2002. 476 [BA03] Blanton, E. and M. Allman, Using TCP DSACKs and SCTP 477 Duplicate TSNs to Detect Spurious Retransmissions, draft- 478 ietf-tsvwg-dsack-use-02.txt (work in progress), 479 October 2003. 481 [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, 482 A Conservative SACK-based Loss Recovery Algorithm for TCP, 483 RFC3517, April 2003. 485 [GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm 486 for TCP in a GPRS Network, In Proceedings of the European 487 Wireless Conference, February 2002. 489 [GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts 490 in TCP, In Proceedings of IEEE INFOCOM 03, . 492 [Jac88] Jacobson, V., Congestion Avoidance and Control, In 493 Proceedings of ACM SIGCOMM 88. 495 [KP87] Karn, P. and C. Partridge, Improving Round-Trip Time 496 Estimates in Reliable Transport Protocols, In Proceedings 497 of ACM SIGCOMM 87. 499 [LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP 500 Robust Against Spurious Retransmissions, ACM Computer 501 Communication Review, Vol. 30, No. 1, January 2000. 503 [SK03] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for 504 Detecting Spurious Retransmission Timeouts with TCP and 505 SCTP, draft-ietf-tsvwg-tcp-frto-00.txt (work in progress), 506 October 2003. 508 [WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, 509 Volume 2 (The Implementation), Addison Wesley, 510 January 1995. 512 [Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings 513 of ACM SIGCOMM 88. 515 Author's Address 517 Reiner Ludwig 518 Ericsson Research (EED) 519 Ericsson Allee 1 520 52134 Herzogenrath, Germany 521 Email: Reiner.Ludwig@ericsson.com 523 Andrei Gurtov 524 TeliaSonera Finland 525 P.O. Box 970, FIN-00051 Sonera 526 Helsinki, Finland 527 Email: andrei.gurtov@teliasonera.com 528 Homepage: http://www.cs.helsinki.fi/u/gurtov 530 This Internet-Draft expires in April 2004.