idnits 2.17.1 draft-ietf-tsvwg-tcp-eifel-alg-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 9 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 10 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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) == Missing Reference: 'RFC1122' is mentioned on line 394, but not defined ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2582 (Obsoleted by RFC 3782) -- Possible downref: Non-RFC (?) normative reference: ref. 'Gu01' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac88' ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'KP87' -- Possible downref: Non-RFC (?) normative reference: ref. 'LK00' -- Possible downref: Non-RFC (?) normative reference: ref. 'LG02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lu02' ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'WS95' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: January 2003 Ericsson Research 5 July, 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 fast retransmit has been sent. The algorithm requires that the TCP 37 Timestamps option defined in RFC1323 is enabled for a connection. The 38 idea is to use the timestamps echoed in returning ACKs to eliminate 39 the retransmission ambiguity in TCP. The Eifel detection algorithm 40 provides a basis for future TCP enhancements. This includes response 41 algorithms to back out of loss recovery by restoring a TCP sender's 42 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 [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, the loss of a flight of ACKs, or a sudden delay 86 increase in the data or the ACK path that results in a spurious 87 timeout. For example, such sudden delay increases can often occur in 88 wide-area wireless access networks due to handovers, resource 89 preemption due to higher priority traffic (e.g., voice), or because 90 the mobile transmitter traverses through a radio coverage hole (e.g., 91 see [Gu01]). In such wireless networks, the often unnecessary 92 go-back-N retransmits that typically occur after a spurious timeout 93 create a serious problem. They decrease end-to-end throughput, are 94 useless load upon a potentially congested network, and waste 95 transmission (battery) power. 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 The common understanding of a spurious timeout is a timeout that 133 would not have occurred had the sender "waited longer". This may be 134 caused by increased delay that suddenly occurs in the data and/or the 135 ACK path. That in turn might cause an acceptable ACK to arrive too 136 late, i.e., only after the TCP sender's retransmission timer has 137 expired. For the purpose of specifying the algorithm in Section 3, we 138 define this case as SPUR_TO (equal 1). However, in this document, we 139 stretch the definition of a spurious timeout. We also speak of a 140 spurious timeout when the timeout occurred because an entire flight 141 of ACKs was lost while in fact the original transmit of the oldest 142 outstanding segment had arrived at the TCP receiver. This case is 143 also considered to fall under the definition of SPUR_TO since a TCP 144 sender is not able to distinguish it from the other case mentioned 145 above. Such a timeout is certainly unavoidable, i.e., it would not 146 have made a difference if the TCP sender had "waited longer". Still, 147 the triggering of loss recovery was spurious since that original 148 transmit was not lost, i.e., there had been no congestion in the data 149 path. Hence, we use the term 'spurious timeout' in the sense that 150 initiating the associated loss recovery was unnecessary. Yet, we 151 exclude from the definition of a spurious timeout the case where the 152 retransmit arrives at the TCP receiver before the corresponding 153 original transmit. 155 Note: There is another case where a timeout would not have 156 occurred had the sender "waited longer": the retransmission 157 timer expires, and afterwards the TCP sender receives the 158 duplicate ACK that would have triggered a fast retransmit of the 159 oldest outstanding segment. We call this a "fast timeout" since 160 in competition with the fast retransmit algorithm the timeout 161 was faster. However, a fast timeout is not spurious since 162 apparently a segment was in fact lost, i.e., loss recovery was 163 initiating rightfully. In this document, we do not consider fast 164 timeouts. This case is addressed in an independent document 165 [Lu02]. 167 Packet reordering in the network may occur because IP [RFC791] does 168 not guarantee in-order delivery of packets. Additionally, a TCP 169 receiver generates a duplicate ACK for each segment that arrives out- 170 of-order. This results in a spurious fast retransmit if three or more 171 data segments arrive out-of-order at the TCP receiver, and at least 172 three of the resulting duplicate ACKs arrive at the TCP sender. This 173 assumes that the duplicate acknowledgement threshold is set to three 174 as defined in [RFC2581]. 176 Packet duplication may occur because a receiving IP does not (cannot) 177 remove packets that have been duplicated in the network. A TCP 178 receiver in turn also generates a duplicate ACK for each duplicate 179 segment. As with packet reordering, this results in a spurious fast 180 retransmit if duplication of data segments or ACKs results in three 181 or more duplicate ACKs to arrive at the TCP sender. Again, this 182 assumes that the duplicate acknowledgement threshold is set to three. 184 The negative impact on TCP performance caused by packet reordering 185 and packet duplication is commonly the same: a single spurious 186 retransmit (the fast retransmit), and the unnecessary halving of the 187 TCP sender's congestion window as a result of the subsequent fast 188 recovery phase [RFC2581]. 190 The negative impact on TCP performance caused by a spurious timeout 191 is more severe. First, the timeout event itself causes a single 192 spurious retransmit, and unnecessarily forces the TCP sender into 193 slow start [RFC2581]. Then, as the connection progresses, a chain 194 reaction gets triggered that further decreases TCP's performance. 196 Since the timeout was spurious, at least some ACKs for original 197 transmits will typically arrive at the TCP sender before the ACK for 198 the retransmit arrives. (This is unless severe packet reordering 199 coincided with the spurious timeout in such a way that the ACK for 200 the retransmit is the first acceptable ACK to arrive at the TCP 201 sender.) Those ACKs for original transmits will then trigger an 202 implicit go-back-N loss recovery at the TCP sender. Assuming that 203 none of the outstanding segments and none of the corresponding ACKs 204 were lost, all outstanding segments will get retransmitted 205 unnecessarily. In fact, during this phase the TCP sender breaks 206 'packet conservation' [Jac88]. This is because the unnecessary 207 go-back-N retransmits are sent during slow start, i.e., for each 208 original packet leaving the network, two useless retransmits are sent 209 into the network. Moreover, some TCPs will in addition suffer from a 210 spurious fast retransmit. This is because the spurious go-back-N 211 retransmits will arrive as duplicates at the TCP receiver, which in 212 turn triggers a series of duplicate ACKs. Note that this last 213 spurious fast retransmit could be avoided with the careful variant of 214 'bug fix' [RFC2582]. 216 More detailed explanations including TCP trace plots that visualize 217 the effects of spurious timeouts and packet reordering can be found 218 in [LK00]. 220 3. The Eifel Detection Algorithm 222 3.1 The Idea 224 The goal of the Eifel detection algorithm is to allow the TCP sender 225 to detect a posteriori whether it has entered loss recovery 226 unnecessarily. Furthermore, the TCP sender should be able to make 227 this decision upon the first acceptable ACK that arrives after the 228 timeout-based retransmit or the fast retransmit has been sent. This 229 in turn requires extra information in every ACK by which the TCP 230 sender can unambiguously distinguish whether that first acceptable 231 ACK was sent in response to the original transmit or the retransmit. 232 Such extra information is provided by the TCP Timestamps option 233 [RFC1323]. Generally speaking, timestamps are monotonously increasing 234 "serial numbers" added into every segment that are then echoed within 235 the corresponding ACKs. This is exploited by the Eifel detection 236 algorithm in the following way. 238 Given that timestamps are enabled for a connection, the TCP sender 239 always stores the timestamp of the retransmit sent in the beginning 240 of loss recovery, i.e., the timestamp of the timeout-based retransmit 241 or the fast retransmit. If the timestamp of the first acceptable ACK, 242 arriving after the retransmit was sent, is smaller then the stored 243 timestamp of that retransmit, then that ACK must have been sent in 244 response to an original transmit. Hence, the TCP sender must have 245 entered loss recovery unnecessarily. 247 The fact that the Eifel detection algorithm decides upon the first 248 acceptable ACK is crucial to allow future response algorithms to 249 avoid the spurious go-back-N retransmits that typically occur after a 250 spurious timeout. Also, if loss recovery was entered unnecessarily, a 251 window worth of ACKs are outstanding that all carry a timestamp that 252 is smaller than the stored timestamp of the retransmit. The arrival 253 of any one of those ACKs suffices the Eifel detection algorithm to 254 work. Hence, the solution is fairly robust against ACK losses. Even 255 the ACK sent in response to the retransmit, i.e., the one that 256 carries the stored timestamp, may get lost. 258 Note: Also the DSACK option [RFC2883] can be used to detect a 259 posteriori whether the TCP sender has entered loss recovery 260 unnecessarily. However, the first ACK carrying a DSACK option 261 usually arrives at the TCP sender only after loss recovery has 262 already terminated. Thus, the DSACK option cannot be used to 263 eliminate the retransmission ambiguity. Consequently, it cannot 264 be used to avoid the mentioned spurious go-back-N retransmits. 265 Moreover, a DSACK-based detection algorithm is less robust 266 against ACK losses. 268 3.2 The Algorithm 270 Given that the TCP Timestamps option [RFC1323] is enabled for a 271 connection, a TCP sender MAY use the Eifel detection algorithm as 272 defined in this subsection. 274 If the Eifel detection algorithm is used, the following steps MUST be 275 taken by the TCP sender, but only upon initiation of loss recovery, 276 i.e., when either the timeout-based retransmit or the fast retransmit 277 is sent. The Eifel detection algorithm MUST NOT be reinitiated after 278 loss recovery has already started. In particular, it may not be 279 reinitiated upon subsequent timeouts for the same segment, and not 280 upon retransmitting segments other than the oldest outstanding 281 segment, e.g., during selective loss recovery. 283 (1) Set a "RetransmitTS" variable to the value of the 284 Timestamp Value field of the Timestamps option included 285 in the retransmit sent when loss recovery is initiated. A 286 TCP sender must ensure that RetransmitTS does not get 287 overwritten as loss recovery progresses, e.g., in case of 288 a second timeout and subsequent second retransmit of the 289 same octet. 291 (2) Set a "SpuriousRecovery" variable to FALSE. 293 (3) Wait for the arrival of an acceptable ACK. If an 294 acceptable ACK has arrived, then proceed to step (4). 296 (4) If the value of the Timestamp Echo Reply field of the 297 acceptable ACK's Timestamps option is smaller than the 298 value of the variable RetransmitTS, then proceed to step 299 (5), 301 else proceed to step (DONE). 303 (5) If the loss recovery has been initiated with a timeout- 304 based retransmit, then set 305 SpuriousRecovery <- SPUR_TO, 307 else set 308 SpuriousRecovery <- dupacks+1 310 (RESP) Do nothing (Placeholder for a response algorithm). 312 (DONE) No further processing. 314 The comparison "smaller than" in step (4) is conservative. In theory, 315 when the "timestamp clock" is slow or the network is fast, 316 RetransmitTS could at most be equal to the timestamp echoed by an ACK 317 sent in response to an original transmit. In that case, it is assumed 318 that the loss recovery was not falsely triggered. 320 3.3 Non-RFC1323-compliant TCP Receivers Mask Certain Spurious Timeouts 322 Not all TCP implementations strictly follow RFC1323. There are 323 differences concerning which timestamp a TCP receiver echoes when a 324 duplicate segment arrives. The relevant case to consider in this 325 context is a spurious timeout that occurred because an entire flight 326 of ACKs got lost (recall the definition of a spurious timeout from 327 Section 2). The question is which timestamp the TCP receiver echoes 328 in response to the spurious retransmit that typically arrives as a 329 duplicate segment. RFC1323-compliant TCP receivers (e.g., LINUX 330 kernel 2.4.x) will echo the timestamp of the last segment that 331 arrived in-sequence, while some non-RFC1323-compliant TCP receivers 332 will echo the timestamp of the retransmit. 334 The Eifel detection algorithm will only detect such spurious timeouts 335 in case the TCP receiver is RFC1323-compliant in this respect. 336 Otherwise, the Eifel detection algorithm will simply not kick in. 337 This is not any different than from running the TCP sender without 338 the Eifel algorithm. 340 3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant) 342 A TCP receiver can easily make a genuine retransmit appear to the TCP 343 sender as a spurious retransmit by forging echoed timestamps. This 344 may pose a security concern. 346 Fortunately, there is a way to modify the Eifel detection algorithm 347 in a way that makes it robust against lying TCP receivers. The idea 348 is to use timestamps as a "segment's secret" that the TCP receiver 349 only gets to know if it receives the segment. Conversely, a TCP 350 receiver will not know the timestamp of a segment that was lost. 351 Hence, to "prove" that it received the original transmit of a segment 352 that the TCP sender retransmitted, the TCP receiver would need to 353 return the timestamp of that original transmit. The Eifel detection 354 algorithm could then be modified to only decide that loss recovery 355 has been unnecessarily entered if the first acceptable ACK echoes the 356 timestamp of the original transmit. 358 Hence, implementers may choose to implement the algorithm with the 359 following modifications. 361 Step (1) is replaced with step (1'): 363 (1') Set a "RetransmitTS" variable to the value of the 364 Timestamp Value field of the Timestamps option that was 365 included in the original transmit corresponding to the 366 retransmit. Note: This step requires that the TCP sender 367 stores the timestamps of all outstanding original 368 transmits. 370 Step (4) is replaced with step (4'): 372 (4') If the value of the Timestamp Echo Reply field of the 373 acceptable ACK's Timestamps option is equal to the value 374 of the variable RetransmitTS, then proceed to step (5), 376 else proceed to step (DONE). 378 These modifications come at a cost: the modified algorithm is fairly 379 sensitive against ACK losses since it relies on the arrival of the 380 acceptable ACK that corresponds to the original transmit. 382 Note: The first acceptable ACK that arrives after loss recovery 383 has been unnecessarily entered, should echo the timestamp of the 384 original transmit. This assumes that the ACK corresponding to 385 the original transmit was not lost, that that ACK was not 386 reordered in the network, and that the TCP receiver does not 387 forge timestamps but complies with RFC1323. In case of a 388 spurious fast retransmit, this is implied by the rules for 389 generating ACKs for data segments that fill in all or part of a 390 gap in the sequence space (see section 4.2 of [RFC2581]) and by 391 the rules for echoing timestamps in that case (see rule (C) in 392 section 3.4 of [RFC1323]). In case of a spurious timeout, it is 393 likely that the delay that has caused the spurious timeout has 394 also caused the TCP receiver's delayed ACK timer [RFC1122] to 395 expire before the original transmit arrives. Also, in this case 396 the rules for generating ACKs and the rules for echoing 397 timestamps (see rule (A) in section 3.4 of [RFC1323]) ensure 398 that the original transmit's timestamp is echoed. 400 A remaining problem is that a TCP receiver might guess a lost 401 segment's timestamp from observing the timestamps of segments that 402 arrived earlier. This could be avoided by having the TCP sender add a 403 "random counter" to the timestamp of every segment it sends, and then 404 increment that counter by a random value, e.g., between 1 and 100. 405 This ensures that timestamps remain monotonously increasing while 406 making it difficult for a TCP receiver to guess the timestamp of a 407 lost segment. 409 4. Security Considerations 411 There do not seem to be any security considerations associated with 412 the Eifel detection algorithm. This is because the Eifel detection 413 algorithm does not alter existing protocol state at the TCP sender 414 nor at the receiver. That is, no value of a TCP sender's state 415 variable is changed. 417 Moreover, a variant of the Eifel detection algorithm has been 418 proposed in Section 3.4 that makes it robust against lying TCP 419 receivers. 421 Acknowledgments 423 Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally 424 Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi 425 Sarolahti, and Alexey Kuznetsov for useful discussions that 426 contributed to this work. 428 References 430 [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, 431 RFC 2581, April 1999. 433 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 434 Requirement Levels, RFC 2119, March 1997. 436 [RFC2582] S. Floyd, T. Henderson, The NewReno Modification to TCP's 437 Fast Recovery Algorithm, RFC 2582, April 1999. 439 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, 440 An Extension to the Selective Acknowledgement (SACK) Option 441 for TCP, RFC 2883, July 2000. 443 [Gu01] A. Gurtov, Effect of Delays on TCP Performance, In 444 Proceedings of IFIP Personal Wireless Communications, 445 August 2001. 447 [Jac88] V. Jacobson, Congestion Avoidance and Control, In 448 Proceedings of ACM SIGCOMM 88. 450 [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High 451 Performance, RFC 1323, May 1992. 453 [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates 454 in Reliable Transport Protocols, In Proceedings of ACM 455 SIGCOMM 87. 457 [LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP 458 Robust Against Spurious Retransmissions, ACM Computer 459 Communication Review, Vol. 30, No. 1, January 2000, 460 available at http://www.acm.org/sigcomm/ccr/archive/2000/ 461 jan00/ccr-200001-ludwig.html (easier studied when 462 viewed/printed in color). 464 [LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm for TCP, 465 work in progress, July 2002. 467 [Lu02] R. Ludwig, Responding to Fast Timeouts in TCP, work in 468 progress, July 2002. 470 [RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, 471 RFC 2988, November 2000. 473 [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. 475 [RFC793] J. Postel, Transmission Control Protocol, RFC793, September 476 1981. 478 [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 479 (The Implementation), Addison Wesley, January 1995. 481 Author's Address 483 Reiner Ludwig 484 Ericsson Research 485 Ericsson Allee 1 486 52134 Herzogenrath, Germany 487 Email: Reiner.Ludwig@eed.ericsson.se 489 Michael Meyer 490 Ericsson Research 491 Ericsson Allee 1 492 52134 Herzogenrath, Germany 493 Email: Michael.Meyer@eed.ericsson.se 495 This Internet-Draft expires in January 2003.