idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-alg-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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 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]), 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 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 (~~), 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 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 the TCP sender to detect a 33 posteriori whether it has entered loss recovery unnecessarily. It 34 already determines this in the beginning of loss recovery when the 35 first acceptable ACK arrives after the timeout-based retransmit or 36 the fast retransmit has been sent. The algorithm requires that the 37 TCP Timestamps option defined in RFC1323 is enabled for a connection. 38 The idea is to use the timestamps echoed in returning ACKs to 39 eliminate the retransmission ambiguity in TCP. The Eifel detection 40 algorithm provides a basis for future TCP enhancements. This includes 41 response algorithms to back out of loss recovery by restoring a TCP 42 sender's congestion 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 57 algorithm 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 the TCP sender before the fast retransmit is sent. 65 We 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 the 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 the 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 the TCP sender to detect 80 a posteriori whether it has entered loss recovery unnecessarily. 82 This added capability of the TCP sender is useful in environments 83 where TCP's loss recovery and congestion control algorithms may often 84 get falsely triggered. This can be caused by packet reordering, 85 packet duplication, or a sudden delay increase in the data or the ACK 86 path that results in a spurious timeout. For example, such sudden 87 delay increases can often occur in wide-area wireless access networks 88 due 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 a potentially congested 94 network, and waste transmission (battery) power. Note, that across 95 such networks the use of timestamps is recommended anyway [IMLGK02]. 97 Based on the Eifel detection algorithm, the TCP sender may then 98 choose 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 2. Events that Falsely Trigger TCP Loss Recovery 121 The following events falsely trigger a TCP sender's loss recovery and 122 congestion control algorithms. This causes a so-called spurious 123 retransmit, and an unnecessary reduction of the TCP sender's 124 congestion window and slow start threshold [RFC2581]. 126 - Spurious timeout 128 - Packet reordering 130 - Packet duplication 132 A spurious timeout is a timeout that would not have occurred had the 133 sender "waited longer". This may be caused by increased delay that 134 suddenly occurs in the data and/or the ACK path. That in turn might 135 cause an acceptable ACK to arrive too late, i.e., only after the TCP 136 sender's retransmission timer has expired. For the purpose of 137 specifying the algorithm in Section 3, we define this case as SPUR_TO 138 (equal 1). 140 Note: There is another case where a timeout would not have 141 occurred had the sender "waited longer": the retransmission 142 timer expires, and afterwards the TCP sender receives the 143 duplicate ACK that would have triggered a fast retransmit of the 144 oldest outstanding segment. We call this a "fast timeout" since 145 in competition with the fast retransmit algorithm the timeout 146 was faster. However, a fast timeout is not spurious since 147 apparently a segment was in fact lost, i.e., loss recovery was 148 initiated rightfully. In this document, we do not consider fast 149 timeouts. This case is addressed in an independent document 150 [Lu02]. 152 Packet reordering in the network may occur because IP [RFC791] does 153 not guarantee in-order delivery of packets. Additionally, a TCP 154 receiver generates a duplicate ACK for each segment that arrives out- 155 of-order. This results in a spurious fast retransmit if three or more 156 data segments arrive out-of-order at the TCP receiver, and at least 157 three of the resulting duplicate ACKs arrive at the TCP sender. This 158 assumes that the duplicate acknowledgement threshold is set to three 159 as defined in [RFC2581]. 161 Packet duplication may occur because a receiving IP does not (cannot) 162 remove packets that have been duplicated in the network. A TCP 163 receiver in turn also generates a duplicate ACK for each duplicate 164 segment. As with packet reordering, this results in a spurious fast 165 retransmit if duplication of data segments or ACKs results in three 166 or more duplicate ACKs to arrive at the TCP sender. Again, this 167 assumes that the duplicate acknowledgement threshold is set to three. 169 The negative impact on TCP performance caused by packet reordering 170 and packet duplication is commonly the same: a single spurious 171 retransmit (the fast retransmit), and the unnecessary halving of the 172 TCP sender's congestion window as a result of the subsequent fast 173 recovery phase [RFC2581]. 175 The negative impact on TCP performance caused by a spurious timeout 176 is more severe. First, the timeout event itself causes a single 177 spurious retransmit, and unnecessarily forces the TCP sender into 178 slow start [RFC2581]. Then, as the connection progresses, a chain 179 reaction gets triggered that further decreases TCP's performance. 180 Since the timeout was spurious, at least some ACKs for original 181 transmits will typically arrive at the TCP sender before the ACK for 182 the retransmit arrives. (This is unless severe packet reordering 183 coincided with the spurious timeout in such a way that the ACK for 184 the retransmit is the first acceptable ACK to arrive at the TCP 185 sender.) Those ACKs for original transmits will then trigger an 186 implicit go-back-N loss recovery at the TCP sender. Assuming that 187 none of the outstanding segments and none of the corresponding ACKs 188 were lost, all outstanding segments will get retransmitted 189 unnecessarily. In fact, during this phase the TCP sender breaks 190 'packet conservation' [Jac88]. This is because the unnecessary 191 go-back-N retransmits are sent during slow start. Thus, for each 192 packet that leaves the network and that belongs to the first half of 193 the original flight, two useless retransmits are sent into the 194 network. Moreover, some TCPs will in addition suffer from a spurious 195 fast retransmit. This is because the unnecessary go-back-N 196 retransmits will arrive as duplicates at the TCP receiver, which in 197 turn triggers a series of duplicate ACKs. Note that this last 198 spurious fast retransmit could be avoided with the careful variant of 199 'bug fix' [RFC2582]. 201 More detailed explanations including TCP trace plots that visualize 202 the effects of spurious timeouts and packet reordering can be found 203 in the original proposal [LK00]. 205 3. The Eifel Detection Algorithm 207 3.1 The Idea 209 The goal of the Eifel detection algorithm is to allow the TCP sender 210 to detect a posteriori whether it has entered loss recovery 211 unnecessarily. Furthermore, the TCP sender should be able to make 212 this decision upon the first acceptable ACK that arrives after the 213 timeout-based retransmit or the fast retransmit has been sent. This 214 in turn requires extra information in ACKs by which the TCP sender 215 can unambiguously distinguish whether that first acceptable ACK was 216 sent in response to the original transmit or the retransmit. Such 217 extra information is provided by the TCP Timestamps option [RFC1323]. 218 Generally speaking, timestamps are monotonously increasing "serial 219 numbers" added into every segment that are then echoed within the 220 corresponding ACKs. This is exploited by the Eifel detection 221 algorithm in the following way. 223 Given that timestamps are enabled for a connection, the TCP sender 224 always stores the timestamp of the retransmit sent in the beginning 225 of loss recovery, i.e., the timestamp of the timeout-based retransmit 226 or the fast retransmit. If the timestamp of the first acceptable ACK, 227 arriving after the retransmit was sent, is smaller then the stored 228 timestamp of that retransmit, then that ACK must have been sent in 229 response to an original transmit. Hence, the TCP sender must have 230 entered loss recovery unnecessarily. 232 The fact that the Eifel detection algorithm decides upon the first 233 acceptable ACK is crucial to allow future response algorithms to 234 avoid the unnecessary go-back-N retransmits that typically occur 235 after a spurious timeout. Also, if loss recovery was entered 236 unnecessarily, a window worth of ACKs are outstanding that all carry 237 a timestamp that is smaller than the stored timestamp of the 238 retransmit. The arrival of any one of those ACKs suffices the Eifel 239 detection algorithm to work. Hence, the solution is fairly robust 240 against ACK losses. Even the ACK sent in response to the retransmit, 241 i.e., the one that carries the stored timestamp, may get lost. 243 Note: Also the DSACK option [RFC2883] can be used to detect a 244 posteriori whether the TCP sender has entered loss recovery 245 unnecessarily. However, the first ACK carrying a DSACK option 246 usually arrives at the TCP sender only after loss recovery has 247 already terminated. Thus, the DSACK option cannot be used to 248 eliminate the retransmission ambiguity. Consequently, it cannot 249 be used to avoid the mentioned unnecessary go-back-N 250 retransmits. Moreover, a DSACK-based detection algorithm is less 251 robust against ACK losses. 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 the 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 "RetransmitTS" variable to the value of the 269 Timestamp Value field of the Timestamps option included 270 in the retransmit sent when loss recovery is initiated. A 271 TCP sender must ensure that RetransmitTS does not get 272 overwritten as loss recovery progresses, e.g., in case of 273 a second timeout and subsequent second retransmit of the 274 same octet. 276 (2) Set a "SpuriousRecovery" variable to FALSE (equal 0). 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 acceptable ACK neither carries a SACK option 282 [RFC2018] nor a DSACK option [RFC2883], then proceed to 283 step (5), 285 else proceed to step (DONE). 287 (5) If the value of the Timestamp Echo Reply field of the 288 acceptable ACK's Timestamps option is smaller than the 289 value of the variable RetransmitTS, then proceed to step 290 (6), 292 else proceed to step (DONE). 294 (6) If the loss recovery has been initiated with a timeout- 295 based retransmit, then set 296 SpuriousRecovery <- SPUR_TO (equal 1), 298 else set 299 SpuriousRecovery <- dupacks+1 301 (RESP) Do nothing (Placeholder for a response algorithm). 303 (DONE) No further processing. 305 The comparison "smaller than" in step (5) is conservative. In theory, 306 if the "timestamp clock" is slow or the network is fast, RetransmitTS 307 could at most be equal to the timestamp echoed by an ACK sent in 308 response to an original transmit. In that case, it is assumed that 309 the loss recovery was not falsely triggered. 311 3.3 A Corner Case: "Timeout due to loss of all ACKs" 313 The TCP sender is forced into a timeout even though the oldest 314 outstanding segment arrived at the TCP receiver when all ACKs are 315 lost. Although, the resulting retransmit is unnecessary, such a 316 timeout is unavoidable. It should therefore not be considered to be 317 spurious. 319 The retransmit will arrive as a duplicate at the TCP receiver. In 320 response to duplicates, RFC1323 mandates that the timestamp of the 321 last segment that arrived in-sequence should be echoed. That 322 timestamp will commonly be smaller than the timestamp carried by the 323 retransmit. Consequently, the Eifel detection algorithm will mistake 324 such a timeout as spurious, unless the SACK and DSACK option are 325 enabled for that TCP connection. 327 Note: Not all TCP implementations strictly follow RFC1323. In 328 response to a duplicate data segment, some TCP receivers will 329 echo the timestamp of the duplicate. With such TCP receivers, 330 the corner case discussed in this section does not apply. That 331 is, even though all ACKs were lost, and independent of whether 332 the SACK and DSACK option was enabled for a connection, the 333 Eifel detection algorithm would have no effect. 335 With the SACK and DSACK option the Eifel detection algorithm will 336 detect this corner case. This motivates step (4) of the algorithm. If 337 data segments beyond the oldest outstanding one are also lost, then 338 the first acceptable ACK that arrives during loss recovery will carry 339 a SACK or a DSACK option. That ACK must have been sent in response to 340 a retransmit of the oldest outstanding segment that arrived as a 341 duplicate at the TCP receiver. It carries a SACK option if there are 342 holes in the TCP receiver's sequence space. Otherwise, it carries a 343 DSACK option. 345 A concern with this corner case arises if the Eifel detection 346 algorithm is combined with a response algorithm like the Eifel 347 response algorithm [LG02]. That algorithm will back out of loss 348 recovery by reversing congestion control state after a spurious 349 timeout has been detected. I.e., this would also happen in cases when 350 all ACKs are lost, and the SACK and/or the DSACK option are not used 351 for that connection. The argument against that, is that the TCP 352 sender should keep its congestion window halved in case all ACKs are 353 lost since that is a sign of severe congestion on the ACK path. 355 This is not really a problem as long as data segments were lost in 356 addition to the entire flight of ACKs. The Eifel detection algorithm 357 would misinterpret the timeout as spurious, and the Eifel response 358 algorithm would reverse congestion control state. Still, the TCP 359 sender would respond to congestion (in the data path) as soon as it 360 finds out about the first loss in the outstanding flight. I.e., the 361 TCP sender would still half its congestion window for that flight of 362 packets. 364 The concern remains, though, in case the DSACK option is not enabled, 365 and an entire flight of ACKs is lost while all of the data segments 366 arrive at the TCP receiver. Without the Eifel detection and response 367 algorithm a TCP sender would go into slow start. With those 368 algorithms it would not respond to the congestion in the ACK path. 370 We do not believe that this is a serious concern. First, we assume 371 that DSACK will get increasingly deployed. And even if this was not 372 the case, this special corner case must occur sufficiently often to 373 become a problem for the progress of a TCP connection. This seems 374 rather pathological, since this suggests that the ACK path is pretty 375 much broken. It is unlikely that any TCP could manage to grow its 376 congestion much beyond one maximum segment size with such an ACK 377 path. And in that case, the reversing of congestion control state 378 becomes meaningless. 380 3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant) 382 A TCP receiver can easily make a genuine retransmit appear to the TCP 383 sender as a spurious retransmit by forging echoed timestamps. This 384 may pose a security concern. 386 Fortunately, there is a way to modify the Eifel detection algorithm 387 in a way that makes it robust against lying TCP receivers. The idea 388 is to use timestamps as a "segment's secret" that the TCP receiver 389 only gets to know if it receives the segment. Conversely, a TCP 390 receiver will not know the timestamp of a segment that was lost. 391 Hence, to "prove" that it received the original transmit of a segment 392 that the TCP sender retransmitted, the TCP receiver would need to 393 return the timestamp of that original transmit. The Eifel detection 394 algorithm could then be modified to only decide that loss recovery 395 has been unnecessarily entered if the first acceptable ACK echoes the 396 timestamp of the original transmit. 398 Hence, implementers may choose to implement the algorithm with the 399 following modifications. 401 Step (1) is replaced with step (1'): 403 (1') Set a "RetransmitTS" variable to the value of the 404 Timestamp Value field of the Timestamps option that was 405 included in the original transmit corresponding to the 406 retransmit. Note: This step requires that the TCP sender 407 stores the timestamps of all outstanding original 408 transmits. 410 Step (5) is replaced with step (5'): 412 (5') If the value of the Timestamp Echo Reply field of the 413 acceptable ACK's Timestamps option is equal to the value 414 of the variable RetransmitTS, then proceed to step (6), 416 else proceed to step (DONE). 418 These modifications come at a cost: the modified algorithm is fairly 419 sensitive against ACK losses since it relies on the arrival of the 420 acceptable ACK that corresponds to the original transmit. 422 Note: The first acceptable ACK that arrives after loss recovery 423 has been unnecessarily entered, should echo the timestamp of the 424 original transmit. This assumes that the ACK corresponding to 425 the original transmit was not lost, that that ACK was not 426 reordered in the network, and that the TCP receiver does not 427 forge timestamps but complies with RFC1323. In case of a 428 spurious fast retransmit, this is implied by the rules for 429 generating ACKs for data segments that fill in all or part of a 430 gap in the sequence space (see section 4.2 of [RFC2581]) and by 431 the rules for echoing timestamps in that case (see rule (C) in 432 section 3.4 of [RFC1323]). In case of a spurious timeout, it is 433 likely that the delay (in the data path) that has caused the 434 spurious timeout has also caused the TCP receiver's delayed ACK 435 timer [RFC1122] to expire before the original transmit arrives. 436 Also, in this case the rules for generating ACKs and the rules 437 for echoing timestamps (see rule (A) in section 3.4 of 438 [RFC1323]) ensure that the original transmit's timestamp is 439 echoed. 441 A remaining problem is that a TCP receiver might guess a lost 442 segment's timestamp from observing the timestamps of segments that 443 arrived earlier. This could be avoided by having the TCP sender add a 444 "random counter" to the timestamp of every segment it sends, and then 445 increment that counter by a random value, e.g., between 1 and 100. 447 This ensures that timestamps remain monotonously increasing while 448 making it difficult for a TCP receiver to guess the timestamp of a 449 lost segment. 451 4. Security Considerations 453 There do not seem to be any security considerations associated with 454 the Eifel detection algorithm. This is because the Eifel detection 455 algorithm does not alter existing protocol state at the TCP sender 456 nor at the receiver. That is, no value of a TCP sender's state 457 variable is changed. 459 Moreover, a variant of the Eifel detection algorithm has been 460 proposed in Section 3.4 that makes it robust against lying TCP 461 receivers. 463 Acknowledgments 465 Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally 466 Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi 467 Sarolahti, and Alexey Kuznetsov for useful discussions that 468 contributed to this work. 470 Normative References 472 [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, 473 RFC 2581, April 1999. 475 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 476 Requirement Levels, RFC 2119, March 1997. 478 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, 479 An Extension to the Selective Acknowledgement (SACK) Option 480 for TCP, RFC 2883, July 2000. 482 [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High 483 Performance, RFC 1323, May 1992. 485 [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective 486 Acknowledgement Options, RFC 2018, October 1996. 488 [RFC793] J. Postel, Transmission Control Protocol, RFC793, September 489 1981. 491 Informative References 493 [RFC1122] R. Braden, Requirements for Internet Hosts - Communication 494 Layers, RFC 1122, October 1989. 496 [RFC2582] S. Floyd, T. Henderson, The NewReno Modification to TCP's 497 Fast Recovery Algorithm, RFC 2582, April 1999. 499 [Gu01] A. Gurtov, Effect of Delays on TCP Performance, In 500 Proceedings of IFIP Personal Wireless Communications, 501 August 2001. 503 [IMLGK02] H. Inamura et. al., TCP over Second (2.5G) and Third (3G) 504 Generation Wireless Networks, work in progress, July 2002. 506 [Jac88] V. Jacobson, Congestion Avoidance and Control, In 507 Proceedings of ACM SIGCOMM 88. 509 [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates 510 in Reliable Transport Protocols, In Proceedings of ACM 511 SIGCOMM 87. 513 [LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP 514 Robust Against Spurious Retransmissions, ACM Computer 515 Communication Review, Vol. 30, No. 1, January 2000. 517 [LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm for TCP, 518 work in progress, October 2002. 520 [Lu02] R. Ludwig, Responding to Fast Timeouts in TCP, work in 521 progress, July 2002. 523 [RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, 524 RFC 2988, November 2000. 526 [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. 528 [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 529 (The Implementation), Addison Wesley, January 1995. 531 [Zh86] L. Zhang, Why TCP Timers Don't Work Well, In Proceedings of 532 ACM SIGCOMM 88. 534 Author's Address 536 Reiner Ludwig 537 Ericsson Research 538 Ericsson Allee 1 539 52134 Herzogenrath, Germany 540 Email: Reiner.Ludwig@eed.ericsson.se 542 Michael Meyer 543 Ericsson Research 544 Ericsson Allee 1 545 52134 Herzogenrath, Germany 546 Email: Michael.Meyer@eed.ericsson.se 548 This Internet-Draft expires in April 2003.