idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-alg-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? == 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 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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]), 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) == Unused Reference: 'RFC2018' is defined on line 489, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2582 (Obsoleted by RFC 3782) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) Summary: 8 errors (**), 0 flaws (~~), 5 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 Michael Meyer 4 Expires: April 2003 Ericsson Research 5 October, 2002 7 The Eifel Detection 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 The Eifel detection algorithm allows a TCP sender to detect a 33 posteriori whether it has entered loss recovery unnecessarily. It 34 requires that the TCP Timestamps option defined in RFC1323 is enabled 35 for a connection. The Eifel detection algorithm makes use of the fact 36 that the TCP Timestamps option eliminates the retransmission 37 ambiguity in TCP. Based on the timestamp of the first acceptable ACK 38 that arrives during loss recovery, it decides whether loss recovery 39 was entered unnecessarily. The Eifel detection algorithm provides a 40 basis for future TCP enhancements. This includes response algorithms 41 to back out of loss recovery by restoring a TCP sender's congestion 42 control state. 44 Terminology 46 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 47 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 48 document, are to be interpreted as described in [RFC2119]. 50 We refer to the first-time transmission of an octet as the 'original 51 transmit'. A subsequent transmission of the same octet is referred to 52 as a 'retransmit'. In most cases this terminology can likewise be 53 applied to data segments as opposed to octets. However, with 54 repacketization a segment can contain both first-time transmissions 55 and retransmissions of octets. In that case, this terminology is only 56 consistent when applied to octets. For the Eifel detection algorithm 57 this makes no difference as it also operates correctly when 58 repacketization occurs. 60 We use the term 'acceptable ACK' as defined in [RFC793]. That is an 61 ACK that acknowledges previously unacknowledged data. We use the term 62 'duplicate ACK', and the variable 'dupacks' as defined in [WS95]. The 63 variable 'dupacks' is a counter of duplicate ACKs that have already 64 been received by a TCP sender before the fast retransmit is sent. We 65 use the variable 'DupThresh' to refer to the so-called duplicate 66 acknowledgement threshold, i.e., the number of duplicate ACKs that 67 need to arrive at a TCP sender to trigger a fast retransmit. 68 Currently, DupThresh is specified as a fixed value of three 69 [RFC2581]. Future TCPs might implement an adaptive DupThresh. 71 1. Introduction 73 The retransmission ambiguity problem [Zh86][KP87] is a TCP sender's 74 inability to distinguish whether the first acceptable ACK that 75 arrives after a retransmit, was sent in response to the original 76 transmit or the retransmit. This problem occurs after a timeout-based 77 retransmit and after a fast retransmit. The Eifel detection algorithm 78 uses the TCP Timestamps option defined in [RFC1323] to eliminate the 79 retransmission ambiguity. It thereby allows a TCP sender to detect a 80 posteriori whether it has entered loss recovery unnecessarily. 82 This added capability of a TCP sender is useful in environments where 83 TCP's loss recovery and congestion control algorithms may often get 84 falsely triggered. This can be caused by packet reordering, packet 85 duplication, or a sudden delay increase in the data or the ACK path 86 that results in a spurious timeout. For example, such sudden delay 87 increases can often occur in wide-area wireless access networks due 88 to handovers, resource preemption due to higher priority traffic 89 (e.g., voice), or because the mobile transmitter traverses through a 90 radio coverage hole (e.g., see [Gu01]). In such wireless networks, 91 the often unnecessary go-back-N retransmits that typically occur 92 after a spurious timeout create a serious problem. They decrease end- 93 to-end throughput, are useless load upon the network, and waste 94 transmission (battery) power. Note, that across such networks the use 95 of timestamps is recommended anyway [IMLGK02]. 97 Based on the Eifel detection algorithm, a TCP sender may then choose 98 to implement dedicated response algorithms. One goal of such a 99 response algorithm would be to alleviate the consequences of a 100 falsely triggered loss recovery. This may include restoring the TCP 101 sender's congestion control state, and avoiding the mentioned 102 unnecessary go-back-N retransmits. Another goal would be to adapt 103 protocol parameters such as the duplicate acknowledgement threshold 104 [RFC2581], and the RTT estimators [RFC2988]. This is to reduce the 105 risk of falsely triggering TCP's loss recovery again as the 106 connection progresses. However, such response algorithms are outside 107 the scope of this document. Note: The original proposal, the "Eifel 108 algorithm" [LK00], comprises both a detection and a response 109 algorithm. This document only defines the detection part. The 110 response part is defined in [LG02]. 112 A key feature of the Eifel detection algorithm is that it already 113 detects upon the first acceptable ACK that arrives during loss 114 recovery whether a fast retransmit or a timeout was spurious. This is 115 crucial to be able to avoid the mentioned go-back-N retransmits. 116 Another feature is that the Eifel detection algorithm is fairly 117 robust against the loss of ACKs. 119 Also the DSACK option [RFC2883] can be used to detect a posteriori 120 whether a TCP sender has entered loss recovery unnecessarily [BA02]. 121 However, the first ACK carrying a DSACK option usually arrives at the 122 TCP sender only after loss recovery has already terminated. Thus, the 123 DSACK option cannot be used to eliminate the retransmission 124 ambiguity. Consequently, it cannot be used to avoid the mentioned 125 unnecessary go-back-N retransmits. Moreover, a DSACK-based detection 126 algorithm is less robust against ACK losses. A recent proposal 127 neither based on the TCP timestamps nor the DSACK option does not 128 have the limitation of DSACK-based schemes, but only addresses the 129 case of spurious timeouts [SK02]. 131 2. Events that Falsely Trigger TCP Loss Recovery 133 The following events may falsely trigger a TCP sender's loss recovery 134 and congestion control algorithms. This causes a so-called spurious 135 retransmit, and an unnecessary reduction of the TCP sender's 136 congestion window and slow start threshold [RFC2581]. 138 - Spurious timeout 140 - Packet reordering 142 - Packet duplication 144 A spurious timeout is a timeout that would not have occurred had the 145 sender "waited longer". This may be caused by increased delay that 146 suddenly occurs in the data and/or the ACK path. That in turn might 147 cause an acceptable ACK to arrive too late, i.e., only after a TCP 148 sender's retransmission timer has expired. For the purpose of 149 specifying the algorithm in Section 3, we define this case as SPUR_TO 150 (equal 1). 152 Note: There is another case where a timeout would not have 153 occurred had the sender "waited longer": the retransmission timer 154 expires, and afterwards a TCP sender receives the duplicate ACK 155 that would have triggered a fast retransmit of the oldest 156 outstanding segment. We call this a "fast timeout" since in 157 competition with the fast retransmit algorithm the timeout was 158 faster. However, a fast timeout is not spurious since apparently a 159 segment was in fact lost, i.e., loss recovery was initiated 160 rightfully. In this document, we do not consider fast timeouts. 161 This case is addressed in an independent document [Lu02]. 163 Packet reordering in the network may occur because IP [RFC791] does 164 not guarantee in-order delivery of packets. Additionally, a TCP 165 receiver generates a duplicate ACK for each segment that arrives out- 166 of-order. This results in a spurious fast retransmit if three or more 167 data segments arrive out-of-order at a TCP receiver, and at least 168 three of the resulting duplicate ACKs arrive at the TCP sender. This 169 assumes that the duplicate acknowledgement threshold is set to three 170 as defined in [RFC2581]. 172 Packet duplication may occur because a receiving IP does not (cannot) 173 remove packets that have been duplicated in the network. A TCP 174 receiver in turn also generates a duplicate ACK for each duplicate 175 segment. As with packet reordering, this results in a spurious fast 176 retransmit if duplication of data segments or ACKs results in three 177 or more duplicate ACKs to arrive at a TCP sender. Again, this assumes 178 that the duplicate acknowledgement threshold is set to three. 180 The negative impact on TCP performance caused by packet reordering 181 and packet duplication is commonly the same: a single spurious 182 retransmit (the fast retransmit), and the unnecessary halving of a 183 TCP sender's congestion window as a result of the subsequent fast 184 recovery phase [RFC2581]. 186 The negative impact on TCP performance caused by a spurious timeout 187 is more severe. First, the timeout event itself causes a single 188 spurious retransmit, and unnecessarily forces a TCP sender into slow 189 start [RFC2581]. Then, as the connection progresses, a chain reaction 190 gets triggered that further decreases TCP's performance. Since the 191 timeout was spurious, at least some ACKs for original transmits 192 typically arrive at the TCP sender before the ACK for the retransmit 193 arrives. (This is unless severe packet reordering coincided with the 194 spurious timeout in such a way that the ACK for the retransmit is the 195 first acceptable ACK to arrive at the TCP sender.) Those ACKs for 196 original transmits then trigger an implicit go-back-N loss recovery 197 at the TCP sender. Assuming that none of the outstanding segments and 198 none of the corresponding ACKs were lost, all outstanding segments 199 get retransmitted unnecessarily. In fact, during this phase the TCP 200 sender breaks 'packet conservation' [Jac88]. This is because the 201 unnecessary go-back-N retransmits are sent during slow start. Thus, 202 for each packet that leaves the network and that belongs to the first 203 half of the original flight, two useless retransmits are sent into 204 the network. Moreover, some TCPs in addition suffer from a spurious 205 fast retransmit. This is because the unnecessary go-back-N 206 retransmits arrive as duplicates at the TCP receiver, which in turn 207 triggers a series of duplicate ACKs. Note that this last spurious 208 fast retransmit could be avoided with the careful variant of 'bug 209 fix' [RFC2582]. 211 More detailed explanations including TCP trace plots that visualize 212 the effects of spurious timeouts and packet reordering can be found 213 in the original proposal [LK00]. 215 3. The Eifel Detection Algorithm 217 3.1 The Idea 219 The goal of the Eifel detection algorithm is to allow a TCP sender to 220 detect a posteriori whether it has entered loss recovery 221 unnecessarily. Furthermore, the TCP sender should be able to make 222 this decision upon the first acceptable ACK that arrives after the 223 timeout-based retransmit or the fast retransmit has been sent. This 224 in turn requires extra information in ACKs by which the TCP sender 225 can unambiguously distinguish whether that first acceptable ACK was 226 sent in response to the original transmit or the retransmit. Such 227 extra information is provided by the TCP Timestamps option [RFC1323]. 228 Generally speaking, timestamps are monotonously increasing "serial 229 numbers" added into every segment that are then echoed within the 230 corresponding ACKs. This is exploited by the Eifel detection 231 algorithm in the following way. 233 Given that timestamps are enabled for a connection, the TCP sender 234 always stores the timestamp of the retransmit sent in the beginning 235 of loss recovery, i.e., the timestamp of the timeout-based retransmit 236 or the fast retransmit. If the timestamp of the first acceptable ACK, 237 that arrives after the retransmit was sent, is smaller then the 238 stored timestamp of that retransmit, then that ACK must have been 239 sent in response to an original transmit. Hence, the TCP sender must 240 have entered loss recovery unnecessarily. 242 The fact that the Eifel detection algorithm decides upon the first 243 acceptable ACK is crucial to allow future response algorithms to 244 avoid the unnecessary go-back-N retransmits that typically occur 245 after a spurious timeout. Also, if loss recovery was entered 246 unnecessarily, a window worth of ACKs are outstanding that all carry 247 a timestamp that is smaller than the stored timestamp of the 248 retransmit. The arrival of any one of those ACKs suffices the Eifel 249 detection algorithm to work. Hence, the solution is fairly robust 250 against ACK losses. Even the ACK sent in response to the retransmit, 251 i.e., the one that carries the stored timestamp, may get lost. 253 3.2 The Algorithm 255 Given that the TCP Timestamps option [RFC1323] is enabled for a 256 connection, a TCP sender MAY use the Eifel detection algorithm as 257 defined in this subsection. 259 If the Eifel detection algorithm is used, the following steps MUST be 260 taken by a TCP sender, but only upon initiation of loss recovery, 261 i.e., when either the timeout-based retransmit or the fast retransmit 262 is sent. The Eifel detection algorithm MUST NOT be reinitiated after 263 loss recovery has already started. In particular, it may not be 264 reinitiated upon subsequent timeouts for the same segment, and not 265 upon retransmitting segments other than the oldest outstanding 266 segment, e.g., during selective loss recovery. 268 (1) Set a "SpuriousRecovery" variable to FALSE (equal 0). 270 (2) Set a "RetransmitTS" variable to the value of the 271 Timestamp Value field of the Timestamps option included in 272 the retransmit sent when loss recovery is initiated. A TCP 273 sender must ensure that RetransmitTS does not get 274 overwritten as loss recovery progresses, e.g., in case of 275 a second timeout and subsequent second retransmit of the 276 same octet. 278 (3) Wait for the arrival of an acceptable ACK. When an 279 acceptable ACK has arrived proceed to step (4). 281 (4) If the value of the Timestamp Echo Reply field of the 282 acceptable ACK's Timestamps option is smaller than the 283 value of the variable RetransmitTS, then proceed to step 284 (5), 286 else proceed to step (DONE). 288 (5) If the acceptable ACK does not carry a DSACK option 289 [RFC2883], then proceed to step (6), 291 else proceed to step (DONE). 293 (6) If the loss recovery has been initiated with a timeout- 294 based retransmit, then set 295 SpuriousRecovery <- SPUR_TO (equal 1), 297 else set 298 SpuriousRecovery <- dupacks+1 300 (RESP) Do nothing (Placeholder for a response algorithm). 302 (DONE) No further processing. 304 The comparison "smaller than" in step (4) is conservative. In theory, 305 if the timestamp clock is slow or the network is fast, RetransmitTS 306 could at most be equal to the timestamp echoed by an ACK sent in 307 response to an original transmit. In that case, it is assumed that 308 the loss recovery was not falsely triggered. 310 3.3 A Corner Case: "Timeout due to loss of all ACKs" 312 Even though the oldest outstanding segment arrived at a TCP receiver, 313 the TCP sender is forced into a timeout when all ACKs are lost. 314 Although, the resulting retransmit is unnecessary, such a timeout is 315 unavoidable. It should therefore not be considered to be spurious. 316 This particular case of a timeout is considered in this section. 318 In that case, the retransmit arrives as a duplicate at the TCP 319 receiver. In response to duplicates, RFC1323 mandates that the 320 timestamp of the last segment that arrived in-sequence should be 321 echoed. That timestamp is carried by the first acceptable ACK that 322 arrives at the TCP sender after loss recovery was entered, and is 323 commonly smaller than the timestamp carried by the retransmit. 324 Consequently, the Eifel detection algorithm mistakes such a timeout 325 as spurious, unless that first acceptable ACK also carries a DSACK 326 option (see step (5) of the algorithm). 328 Note: Not all TCP implementations strictly follow RFC1323. In 329 response to a duplicate data segment, some TCP receivers echo the 330 timestamp of the duplicate. With such TCP receivers, the corner 331 case discussed in this section does not apply. The timestamp 332 carried by the retransmit would be echoed in the first acceptable 333 ACK, and the Eifel detection algorithm would be terminated through 334 step (4). Thus, even though all ACKs were lost, and independent of 335 whether the DSACK option was enabled for a connection, the Eifel 336 detection algorithm would have no effect. 338 A concern with this corner case arises if the Eifel detection 339 algorithm is combined with a response algorithm like the Eifel 340 response algorithm [LG02]. That algorithm backs out of loss recovery 341 by reversing congestion control state after a spurious timeout has 342 been detected. The argument against doing so, is that the TCP sender 343 should keep its congestion window halved in case all ACKs are lost 344 since that is a sign of severe congestion on the ACK path. 346 This is not really a problem as long as data segments were lost in 347 addition to the entire flight of ACKs. The Eifel detection algorithm 348 would misinterpret the timeout as spurious, and the Eifel response 349 algorithm would reverse congestion control state. Still, the TCP 350 sender would respond to congestion (in the data path) as soon as it 351 finds out about the first loss in the outstanding flight. I.e., the 352 TCP sender would still half its congestion window for that flight of 353 packets. 355 The concern remains, though, in case the DSACK option is not enabled, 356 and an entire flight of ACKs is lost while all of the data segments 357 arrive at the TCP receiver. Without the Eifel detection and response 358 algorithm the TCP sender would go into slow start. With those 359 algorithms it would not respond to the congestion in the ACK path. 361 We do not believe that this is a serious concern. First, we assume 362 that DSACK will get increasingly deployed. And even if this was not 363 the case, this special corner case must occur sufficiently often to 364 become a problem for the progress of a TCP connection. It is unlikely 365 that any TCP could manage to grow its congestion window much beyond 366 one maximum segment size with such an ACK path. And in that case, the 367 reversing of congestion control state becomes meaningless. Moreover, 368 in an implementation one might choose to disable the Eifel detection 369 algorithm if such an ACK path is encountered. 371 3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant) 373 A TCP receiver can easily make a genuine retransmit appear to a TCP 374 sender as a spurious retransmit by forging echoed timestamps. This 375 may pose a security concern. 377 Fortunately, there is a way to modify the Eifel detection algorithm 378 in a way that makes it robust against lying TCP receivers. The idea 379 is to use timestamps as a "segment's secret" that a TCP receiver only 380 gets to know if it receives the segment. Conversely, a TCP receiver 381 will not know the timestamp of a segment that was lost. Hence, to 382 "prove" that it received the original transmit of a segment that a 383 TCP sender retransmitted, the TCP receiver would need to return the 384 timestamp of that original transmit. The Eifel detection algorithm 385 could then be modified to only decide that loss recovery has been 386 unnecessarily entered if the first acceptable ACK echoes the 387 timestamp of the original transmit. 389 Hence, implementers may choose to implement the algorithm with the 390 following modifications. 392 Step (2) is replaced with step (2'): 394 (2') Set a "RetransmitTS" variable to the value of the 395 Timestamp Value field of the Timestamps option that was 396 included in the original transmit corresponding to the 397 retransmit. Note: This step requires that the TCP sender 398 stores the timestamps of all outstanding original 399 transmits. 401 Step (4) is replaced with step (4'): 403 (4') If the value of the Timestamp Echo Reply field of the 404 acceptable ACK's Timestamps option is equal to the value 405 of the variable RetransmitTS, then proceed to step (5), 407 else proceed to step (DONE). 409 These modifications come at a cost: the modified algorithm is fairly 410 sensitive against ACK losses since it relies on the arrival of the 411 acceptable ACK that corresponds to the original transmit. 413 Note: The first acceptable ACK that arrives after loss recovery 414 has been unnecessarily entered, should echo the timestamp of the 415 original transmit. This assumes that the ACK corresponding to the 416 original transmit was not lost, that that ACK was not reordered in 417 the network, and that the TCP receiver does not forge timestamps 418 but complies with RFC1323. In case of a spurious fast retransmit, 419 this is implied by the rules for generating ACKs for data segments 420 that fill in all or part of a gap in the sequence space (see 421 section 4.2 of [RFC2581]) and by the rules for echoing timestamps 422 in that case (see rule (C) in section 3.4 of [RFC1323]). In case 423 of a spurious timeout, it is likely that the delay (in the data 424 path) that has caused the spurious timeout has also caused the TCP 425 receiver's delayed ACK timer [RFC1122] to expire before the 426 original transmit arrives. Also, in this case the rules for 427 generating ACKs and the rules for echoing timestamps (see rule (A) 428 in section 3.4 of [RFC1323]) ensure that the original transmit's 429 timestamp is echoed. 431 A remaining problem is that a TCP receiver might guess a lost 432 segment's timestamp from observing the timestamps of recently 433 received segments. For example, if segment N was lost while segment 434 N-1 and N+1 have arrived, a TCP receiver could guess the timestamp 435 that lies in the middle of the timestamps of segments N-1 and N+1, 436 and echo it in the ACK for segment N+1. Especially if a TCP sender 437 implements timestamps with a coarse granularity, a misbehaving TCP 438 receiver is likely to be successful with such an approach. In fact, 439 with the 500 ms granularity suggested in [WS95], it even becomes 440 quite likely that the timestamps of segments N-1, N, N+1 are 441 identical. 443 One way to reduce this risk is to implement fine grained timestamps. 444 Note that the granularity of the timestamps is independent of the 445 granularity of the retransmission timer. For example, some TCP 446 implementations run a timestamp clock that even ticks every 447 microsecond. This should make it more difficult for a TCP receiver to 448 guess the timestamp of a lost segment. Alternatively, it might be 449 possible to combine the timestamps with a nonce, as done for the 450 Explicit Congestion Notification (ECN) [RFC3168]. One would need to 451 take care, though, that the timestamps of succeeding segments remain 452 monotonously increasing and do not interfere with the RTT timing 453 defined in [RFC1323]. 455 4. Security Considerations 457 There do not seem to be any security considerations associated with 458 the Eifel detection algorithm. This is because the Eifel detection 459 algorithm does not alter existing protocol state at a TCP sender. 460 Note that the Eifel detection algorithm only requires changes to the 461 implementation of the TCP sender. 463 Moreover, a variant of the Eifel detection algorithm has been 464 proposed in Section 3.4 that makes it robust against lying TCP 465 receivers. 467 Acknowledgments 469 Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally 470 Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi 471 Sarolahti, and Alexey Kuznetsov for useful discussions that 472 contributed to this work. 474 Normative References 476 [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, 477 RFC 2581, April 1999. 479 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 480 Requirement Levels, RFC 2119, March 1997. 482 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, 483 An Extension to the Selective Acknowledgement (SACK) Option 484 for TCP, RFC 2883, July 2000. 486 [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High 487 Performance, RFC 1323, May 1992. 489 [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective 490 Acknowledgement Options, RFC 2018, October 1996. 492 [RFC793] J. Postel, Transmission Control Protocol, RFC793, September 493 1981. 495 Informative References 497 [BA02] E. Blanton, M. Allman, Using TCP DSACKs and SCTP Duplicate 498 TSNs to Detect Spurious Retransmissions, work in progress, 499 October 2002.. 501 [RFC1122] R. Braden, Requirements for Internet Hosts - Communication 502 Layers, RFC 1122, October 1989. 504 [RFC2582] S. Floyd, T. Henderson, The NewReno Modification to TCP's 505 Fast Recovery Algorithm, RFC 2582, April 1999. 507 [Gu01] A. Gurtov, Effect of Delays on TCP Performance, In 508 Proceedings of IFIP Personal Wireless Communications, 509 August 2001. 511 [IMLGK02] H. Inamura et. al., TCP over Second (2.5G) and Third (3G) 512 Generation Wireless Networks, work in progress, July 2002. 514 [Jac88] V. Jacobson, Congestion Avoidance and Control, In 515 Proceedings of ACM SIGCOMM 88. 517 [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates 518 in Reliable Transport Protocols, In Proceedings of ACM 519 SIGCOMM 87. 521 [LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP 522 Robust Against Spurious Retransmissions, ACM Computer 523 Communication Review, Vol. 30, No. 1, January 2000. 525 [LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm for TCP, 526 work in progress, October 2002. 528 [Lu02] R. Ludwig, Responding to Fast Timeouts in TCP, work in 529 progress, July 2002. 531 [RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, 532 RFC 2988, November 2000. 534 [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. 536 [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of 537 Explicit Congestion Notification (ECN) to IP, RFC 3168, 538 September 2001. 540 [SK02] P. Sarolahti, M. Kojo, F-RTO: A TCP RTO Recovery Algorithm 541 for Avoiding Unnecessary Retransmissions, work in progress, 542 June 2002. 544 [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 545 (The Implementation), Addison Wesley, January 1995. 547 [Zh86] L. Zhang, Why TCP Timers Don't Work Well, In Proceedings of 548 ACM SIGCOMM 88. 550 Author's Address 552 Reiner Ludwig 553 Ericsson Research 554 Ericsson Allee 1 555 52134 Herzogenrath, Germany 556 Email: Reiner.Ludwig@eed.ericsson.se 558 Michael Meyer 559 Ericsson Research 560 Ericsson Allee 1 561 52134 Herzogenrath, Germany 562 Email: Michael.Meyer@eed.ericsson.se 564 This Internet-Draft expires in April 2003.