idnits 2.17.1 draft-ietf-tcpm-frto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 982), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: 'RTO' is mentioned on line 843, but not defined == Missing Reference: 'SACK 8' is mentioned on line 852, but not defined == Unused Reference: 'GL03' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'Sar03' is defined on line 624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2581 (ref. 'APS99') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 3517 (ref. 'BAFW03') (Obsoleted by RFC 6675) ** Obsolete normative reference: RFC 3782 (ref. 'FHG04') (Obsoleted by RFC 6582) ** Obsolete normative reference: RFC 2988 (ref. 'PA00') (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (ref. 'Pos81') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2960 (ref. 'Ste00') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. 'BBJ92') (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. 'Nag84') (Obsoleted by RFC 7805) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Sarolahti 2 INTERNET DRAFT Nokia Research Center 3 File: draft-ietf-tcpm-frto-02.txt M. Kojo 4 University of Helsinki 5 November, 2004 6 Expires: May, 2005 8 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 9 Spurious Retransmission Timeouts with TCP and SCTP 11 Status of this Memo 13 By submitting this Internet-Draft, we certify that any applicable 14 patent or other IPR claims of which we are aware have been disclosed, 15 and any of which we become aware will be disclosed, in accordance 16 with RFC 3668. 18 By submitting this Internet-Draft, we accept the provisions of 19 Section 3 of RFC 3667 (BCP 78). 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 Spurious retransmission timeouts cause suboptimal TCP performance, 44 because they often result in unnecessary retransmission of the last 45 window of data. This document describes the F-RTO detection algorithm 46 for detecting spurious TCP retransmission timeouts. F-RTO is a TCP 47 sender-only algorithm that does not require any TCP options to 48 operate. After retransmitting the first unacknowledged segment 49 triggered by a timeout, the F-RTO algorithm at a TCP sender monitors 50 the incoming acknowledgments to determine whether the timeout was 51 spurious and to decide whether to send new segments or retransmit 52 unacknowledged segments. The algorithm effectively helps to avoid 53 additional unnecessary retransmissions and thereby improves TCP 54 performance in case of a spurious timeout. The F-RTO algorithm can 55 also be applied to SCTP. 57 Terminology 59 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 60 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 61 document, are to be interpreted as described in [RFC2119]. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1 The Algorithm . . . . . . . . . . . . . . . . . . . . . 5 68 2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 6 69 3. SACK-enhanced version of the F-RTO algorithm . . . . . . . . 8 70 4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 10 71 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 77 Appendix B: SACK-enhanced F-RTO and Fast Recovery . . . . . . . . 19 78 Appendix C: Discussion on Window Limited Cases . . . . . . . . . 20 80 1. Introduction 82 The Transmission Control Protocol (TCP) [Pos81] has two methods for 83 triggering retransmissions. First, the TCP sender relies on incoming 84 duplicate ACKs, which indicate that the receiver is missing some of 85 the data. After a required number of successive duplicate ACKs have 86 arrived at the sender, it retransmits the first unacknowledged 87 segment [APS99] and continues with a loss recovery algorithm such as 88 NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the TCP 89 sender maintains a retransmission timer which triggers retransmission 90 of segments, if they have not been acknowledged before the 91 retransmission timeout (RTO) expires. When the retransmission timeout 92 occurs, the TCP sender enters the RTO recovery where the congestion 93 window is initialized to one segment and unacknowledged segments are 94 retransmitted using the slow-start algorithm. The retransmission 95 timer is adjusted dynamically based on the measured round-trip times 96 [PA00]. 98 It has been pointed out that the retransmission timer can expire 99 spuriously and cause unnecessary retransmissions when no segments 100 have been lost [LK00, GL02, LM03]. After a spurious retransmission 101 timeout the late acknowledgments of the original segments arrive at 102 the sender, usually triggering unnecessary retransmissions of a whole 103 window of segments during the RTO recovery. Furthermore, after a 104 spurious retransmission timeout a conventional TCP sender increases 105 the congestion window on each late acknowledgment in slow start, 106 injecting a large number of data segments to the network within one 107 round-trip time, thus violating the packet conservation principle 108 [Jac88]. 110 There are a number of potential reasons for spurious retransmission 111 timeouts. First, some mobile networking technologies involve sudden 112 delay spikes on transmission because of actions taken during a 113 hand-off. Second, arrival of competing traffic, possibly with higher 114 priority, on a low-bandwidth link or some other change in available 115 bandwidth can cause a sudden increase of round-trip time which may 116 trigger a spurious retransmission timeout. A persistently reliable 117 link layer can also cause a sudden delay when a data frame and 118 several retransmissions of it are lost for some reason. This document 119 does not distinguish between the different causes of such a delay 120 spike, but discusses the spurious retransmission timeouts caused by a 121 delay spike in general. 123 This document describes the F-RTO detection algorithm. It is based on 124 the detection mechanism of the "Forward RTO-Recovery" (F-RTO) 125 algorithm [SKR03] that is used for detecting spurious retransmission 126 timeouts and thus avoiding unnecessary retransmissions following the 127 retransmission timeout. When the timeout is not spurious, the F-RTO 128 algorithm reverts back to the conventional RTO recovery algorithm and 129 therefore has similar behavior and performance. In contrast to 130 alternative algorithms proposed for detecting unnecessary 131 retransmissions (Eifel [LK00], [LM03] and DSACK-based algorithms 132 [BA04]), F-RTO does not require any TCP options for its operation, 133 and it can be implemented by modifying only the TCP sender. The 134 Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious 135 timeout upon arrival of the first acknowledgment after the 136 retransmission. The DSACK-based algorithms require that the TCP 137 Selective Acknowledgment Option [MMFR96] with the DSACK extension 138 [FMMP00] is in use. With DSACK, the TCP receiver can report if it has 139 received a duplicate segment, making it possible for the sender to 140 detect afterwards whether it has retransmitted segments 141 unnecessarily. The F-RTO algorithm only attempts to detect and avoid 142 unnecessary retransmissions after an RTO. Eifel and DSACK can also be 143 used for detecting unnecessary retransmissions caused by other 144 events, for example packet reordering. 146 When an RTO expires, the F-RTO sender retransmits the first 147 unacknowledged segment as usual [APS99]. Deviating from the normal 148 operation after a timeout, it then tries to transmit new, previously 149 unsent data, for the first acknowledgment that arrives after the 150 timeout given that the acknowledgment advances the window. If the 151 second acknowledgment that arrives after the timeout also advances 152 the window, i.e., acknowledges data that was not retransmitted, the 153 F-RTO sender declares the timeout spurious and exits the RTO 154 recovery. However, if either of these two acknowledgments is a 155 duplicate ACK, there is no sufficient evidence of a spurious timeout; 156 therefore the F-RTO sender retransmits the unacknowledged segments in 157 slow start similarly to the traditional algorithm. With a 158 SACK-enhanced version of the F-RTO algorithm, spurious timeouts may 159 be detected even if duplicate ACKs arrive after an RTO 160 retransmission. 162 The F-RTO algorithm can also be applied to the Stream Control 163 Transmission Protocol (SCTP) [Ste00], because SCTP has similar 164 acknowledgment and packet retransmission concepts as TCP. For 165 convenience, this document mostly refers to TCP, but the algorithms 166 and other discussion are valid for SCTP as well. 168 This document is organized as follows. Section 2 describes the basic 169 F-RTO algorithm. Section 3 outlines an optional enhancement to the 170 F-RTO algorithm that takes advantage of the TCP SACK option. Section 171 4 discusses the possible actions to be taken after detecting a 172 spurious RTO. Section 5 gives considerations on applying F-RTO with 173 SCTP, and Section 6 discusses the security considerations. 175 2. F-RTO Algorithm 177 A timeout is considered spurious if it would have been avoided had 178 the sender waited longer for an acknowledgment to arrive [LM03]. 179 F-RTO affects the TCP sender behavior only after a retransmission 180 timeout, otherwise the TCP behavior remains the same. When the RTO 181 expires the F-RTO algorithm monitors incoming acknowledgments and 182 declares a timeout spurious, if the TCP sender gets an acknowledgment 183 for a segment that was not retransmitted due to timeout. The actions 184 taken in response to a spurious timeout are not specified in this 185 document, but we discuss some alternatives in Section 4. This section 186 introduces the algorithm and then discusses the different steps of 187 the algorithm in more detail. 189 Following the practice used with the Eifel Detection algorithm 190 [LM03], we use the "SpuriousRecovery" variable to indicate whether 191 the retransmission is declared spurious by the sender. This variable 192 can be used as an input for a corresponding response algorithm. With 193 F-RTO, the value of SpuriousRecovery can be either SPUR_TO, 194 indicating a spurious retransmission timeout, or FALSE, when the 195 timeout is not declared spurious, and the TCP sender should follow 196 the conventional RTO recovery algorithm. 198 2.1. The Algorithm 200 A TCP sender MAY implement the basic F-RTO algorithm, and if it 201 chooses to apply the algorithm, the following steps MUST be taken 202 after the retransmission timer expires. If the sender implements some 203 loss recovery algorithm other than Reno or NewReno [FHG04], F-RTO 204 algorithm SHOULD NOT be entered when earlier fast recovery is 205 underway. 207 1) When RTO expires, retransmit the first unacknowledged segment and 208 set SpuriousRecovery to FALSE. Also, store the highest sequence 209 number transmitted so far in variable "recover". 211 2) When the first acknowledgment after the RTO retransmission arrives 212 at the sender, the sender chooses the following actions depending 213 on whether the ACK advances the window or whether it is a 214 duplicate ACK. 216 a) If the acknowledgment is a duplicate ACK OR it acknowledges a 217 sequence number equal to the value of "recover" OR it does not 218 acknowledge all of the data that was retransmitted in step 1, 219 revert to the conventional RTO recovery and continue by 220 retransmitting unacknowledged data in slow start. Do not enter 221 step 3 of this algorithm. The SpuriousRecovery variable remains 222 as FALSE. 224 b) Else, if the acknowledgment advances the window AND it is below 225 the value of "recover", transmit up to two new (previously 226 unsent) segments and enter step 3 of this algorithm. If the TCP 227 sender does not have enough unsent data, it can send only one 228 segment. In addition, the TCP sender MAY override the Nagle 229 algorithm [Nag84] and immediately send a segment if needed. 230 Note that sending two segments in this step is allowed by TCP 231 congestion control requirements [APS99]: An F-RTO TCP sender 232 simply chooses different segments to transmit. 234 If the TCP sender does not have any new data to send, or the 235 advertised window prohibits new transmissions, the recommended 236 action is to skip step 3 of this algorithm and continue with 237 slow start retransmissions following the conventional RTO 238 recovery algorithm. However, alternative ways of handling the 239 window limited cases that could result in better performance 240 are discussed in Appendix C. 242 3) When the second acknowledgment after the RTO retransmission 243 arrives at the sender, the TCP sender either declares the timeout 244 spurious, or starts retransmitting the unacknowledged segments. 246 a) If the acknowledgment is a duplicate ACK, set the congestion 247 window to no more than 3 * MSS, and continue with the slow 248 start algorithm retransmitting unacknowledged segments. 249 Congestion window can be set to 3 * MSS, because two round-trip 250 times have elapsed since the RTO, and a conventional TCP sender 251 would have increased cwnd to 3 during the same time. Leave 252 SpuriousRecovery set to FALSE. 254 b) If the acknowledgment advances the window, i.e. it acknowledges 255 data that was not retransmitted after the timeout, declare the 256 timeout spurious, set SpuriousRecovery to SPUR_TO and set the 257 value of "recover" variable to SND.UNA, the oldest 258 unacknowledged sequence number [Pos81]. 260 2.2. Discussion 262 The F-RTO sender takes cautious actions when it receives duplicate 263 acknowledgments after a retransmission timeout. Since duplicate ACKs 264 may indicate that segments have been lost, reliably detecting a 265 spurious timeout is difficult due to the lack of additional 266 information. Therefore, it is prudent to follow the conventional TCP 267 recovery in those cases. 269 If the first acknowledgment after the RTO retransmission covers the 270 "recover" point at algorithm step (2a), there is not enough evidence 271 that a non-retransmitted segment has arrived at the receiver after 272 the timeout. This is a common case when a fast retransmission is 273 lost and it has been retransmitted again after an RTO, while the rest 274 of the unacknowledged segments have successfully been delivered to 275 the TCP receiver before the retransmission timeout. Therefore the 276 timeout cannot be declared spurious in this case. 278 If the first acknowledgment after the RTO retransmission does not 279 acknowledge all of the data that was retransmitted in step 1, the TCP 280 sender reverts to the conventional RTO recovery. Otherwise, a 281 malicious receiver acknowledging partial segments could cause the 282 sender to declare the timeout spurious in a case where data was lost. 284 The TCP sender is allowed to send two new segments in algorithm 285 branch (2b), because the conventional TCP sender would transmit two 286 segments when the first new ACK arrives after the RTO retransmission. 287 If sending new data is not possible in algorithm branch (2b), or the 288 receiver window limits the transmission, the TCP sender has to send 289 something in order to prevent the TCP transfer from stalling. If no 290 segments were sent, the pipe between sender and receiver might run 291 out of segments, and no further acknowledgments would arrive. 292 Therefore, in the window limited case the recommendation is to revert 293 to the conventional RTO recovery with slow start retransmissions. 294 Appendix C discusses some alternative solutions for window limited 295 situations. 297 If the retransmission timeout is declared spurious, the TCP sender 298 sets the value of the "recover" variable to SND.UNA in order to allow 299 fast retransmit [FHG04]. The "recover" variable was proposed for 300 avoiding unnecessary multiple fast retransmits when RTO expires 301 during fast recovery with NewReno TCP. As the sender does not 302 retransmit other segments but the one that triggered the timeout, the 303 problem of unnecessary multiple fast retransmits [FHG04] cannot 304 occur. Therefore, if there are three duplicate ACKs arriving at the 305 sender after the timeout, they are likely to indicate a packet loss, 306 hence fast retransmit should be used to allow efficient recovery. If 307 there are not enough duplicate ACKs arriving at the sender after a 308 packet loss, the retransmission timer expires another time and the 309 sender enters step 1 of this algorithm. 311 When the timeout is declared spurious, the TCP sender cannot detect 312 whether the unnecessary RTO retransmission was lost. In principle the 313 loss of the RTO retransmission should be taken as a congestion 314 signal, and thus there is a small possibility that the F-RTO sender 315 violates the congestion control rules, if it chooses to fully revert 316 congestion control parameters after detecting a spurious timeout. The 317 Eifel detection algorithm has a similar property, while the DSACK 318 option can be used to detect whether the retransmitted segment was 319 successfully delivered to the receiver. 321 The F-RTO algorithm has a side-effect on the TCP round-trip time 322 measurement. Because the TCP sender can avoid most of the unnecessary 323 retransmissions after detecting a spurious timeout, the sender is 324 able to take round-trip time samples on the delayed segments. If the 325 regular RTO recovery was used without TCP timestamps, this would not 326 be possible due to the retransmission ambiguity. As a result, the RTO 327 is likely to have more accurate and larger values with F-RTO than 328 with the regular TCP after a spurious timeout that was triggered due 329 to delayed segments. We believe this is an advantage in the networks 330 that are prone to delay spikes. 332 It is possible that the F-RTO algorithm does not always avoid 333 unnecessary retransmissions after a spurious timeout. If packet 334 reordering or packet duplication occurs on the segment that triggered 335 the spurious timeout, the F-RTO algorithm may not detect the spurious 336 timeout due to incoming duplicate ACKs. Additionally, if a spurious 337 timeout occurs during fast recovery, the F-RTO algorithm often cannot 338 detect the spurious timeout, because the segments transmitted before 339 the fast recovery trigger duplicate ACKs. However, we consider these 340 cases relatively rare, and note that in cases where F-RTO fails to 341 detect the spurious timeout, it retransmits the unacknowledged 342 segments in slow start and thus performs similarly to the regular RTO 343 recovery. 345 3. SACK-enhanced version of the F-RTO algorithm 347 This section describes an alternative version of the F-RTO algorithm, 348 that makes use of the TCP Selective Acknowledgment Option [MMFR96]. 349 By using the SACK option the TCP sender can detect spurious timeouts 350 in most of the cases when packet reordering or packet duplication is 351 present. The difference to the basic F-RTO algorithm is that the 352 sender may declare timeout spurious even when duplicate ACKs follow 353 the RTO, if the SACK blocks acknowledge new data that was not 354 transmitted after the RTO retransmission. 356 Given that the TCP Selective Acknowledgment Option [MMFR96] is 357 enabled for a TCP connection, a TCP sender MAY implement the 358 SACK-enhanced F-RTO algorithm. If the sender applies the 359 SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This 360 algorithm SHOULD NOT be applied, if the TCP sender is already in SACK 361 loss recovery when retransmission timeout occurs. However, it should 362 be possible to apply the principle of F-RTO within certain 363 limitations also when retransmission timeout occurs during existing 364 loss recovery. While this is a topic of further research, Appendix B 365 briefly discusses the related issues. 367 1) When the RTO expires, retransmit the first unacknowledged segment 368 and set SpuriousRecovery to FALSE. Set variable "recover" to 369 indicate the highest segment transmitted so far. Following the 370 recommendation in SACK specification [MMFR96], reset the SACK 371 scoreboard. 373 2) Wait until the acknowledgment for the data retransmitted due to 374 the timeout arrives at the sender. If duplicate ACKs arrive before 375 the cumulative acknowledgment for retransmitted data, adjust the 376 scoreboard according to the incoming SACK information but stay in 377 step 2 waiting for the next new acknowledgment. If RTO expires 378 again, go to step 1 of the algorithm. 380 a) if a cumulative ACK acknowledges a sequence number equal to 381 "recover", revert to the conventional RTO recovery and set 382 congestion window to no more than 2 * MSS, like a regular TCP 383 would do. Do not enter step 3 of this algorithm. 385 b) else, if a cumulative ACK acknowledges a sequence number 386 smaller than "recover" but larger than SND.UNA, transmit up to 387 two new (previously unsent) segments and proceed to step 3. If 388 the TCP sender is not able to transmit any previously unsent 389 data due to receiver window limitation or because it does not 390 have any new data to send, the recommended action is to not 391 enter step 3 of this algorithm but continue with slow start 392 retransmissions following the conventional RTO recovery 393 algorithm. 395 It is also possible to apply some of the alternatives for 396 handling window limited cases discussed in Appendix C. In this 397 case, the TCP sender should also follow the recommendations 398 concerning acknowledgments of retransmitted segments given in 399 Appendix B. 401 3) The next acknowledgment arrives at the sender. Either duplicate 402 ACK or a new cumulative ACK advancing the window applies in this 403 step. 405 a) if the ACK acknowledges sequence number above "recover", either 406 in SACK blocks or as a cumulative ACK, set congestion window to 407 no more than 3 * MSS and proceed with the conventional RTO 408 recovery, retransmitting unacknowledged segments. Take this 409 branch also when the acknowledgment is a duplicate ACK and it 410 does not acknowledge any new, previously unacknowledged data 411 below "recover" in the SACK blocks. Leave SpuriousRecovery set 412 to FALSE. 414 b) if the ACK does not acknowledge sequence numbers above 415 "recover" AND it acknowledges data that was not acknowledged 416 earlier either with cumulative acknowledgment or using SACK 417 blocks, declare the timeout spurious and set SpuriousRecovery 418 to SPUR_TO. The retransmission timeout can be declared 419 spurious, because the segment acknowledged with this ACK was 420 transmitted before the timeout. 422 If there are unacknowledged holes between the received SACK blocks, 423 those segments are retransmitted similarly to the conventional SACK 424 recovery algorithm [BAFW03]. If the algorithm exits with 425 SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus 426 allowing fast recovery on incoming duplicate acknowledgments. 428 4. Taking Actions after Detecting Spurious RTO 430 Upon retransmission timeout, a conventional TCP sender assumes that 431 outstanding segments are lost and starts retransmitting the 432 unacknowledged segments. When the retransmission timeout is detected 433 to be spurious, the TCP sender should not continue retransmitting 434 based on the timeout. For example, if the sender was in congestion 435 avoidance phase transmitting new previously unsent segments, it 436 should continue transmitting previously unsent segments after 437 detecting a spurious RTO. This document does not describe the 438 response to spurious timeout, but a response algorithm is described 439 in another IETF document [LG04]. 441 Additionally, different response variants to spurious retransmission 442 timeout have been discussed in various research papers [SKR03, GL03, 443 Sar03] and Internet-Drafts [SL03]. The different response 444 alternatives vary in whether the spurious retransmission timeout 445 should be taken as a congestion signal, thus causing the congestion 446 window or slow start threshold to be reduced at the sender, or 447 whether the congestion control state should be fully reverted to the 448 state valid prior to the retransmission timeout. 450 5. SCTP Considerations 452 SCTP has similar retransmission algorithms and congestion control to 453 TCP. The SCTP T3-rtx timer for one destination address is maintained 454 in the same way than the TCP retransmission timer, and after a T3-rtx 455 expires, an SCTP sender retransmits unacknowledged data chunks in 456 slow start like TCP does. Therefore, SCTP is vulnerable to the 457 negative effects of the spurious retransmission timeouts similarly to 458 TCP. Due to similar RTO recovery algorithms, F-RTO algorithm logic 459 can be applied also to SCTP. Since SCTP uses selective 460 acknowledgments, the SACK-based variant of the algorithm is 461 recommended, although the basic version can also be applied to SCTP. 462 However, SCTP contains features that are not present with TCP that 463 need to be discussed when applying the F-RTO algorithm. 465 SCTP associations can be multi-homed. The current retransmission 466 policy states that retransmissions should go to alternative 467 addresses. If the retransmission was due to spurious timeout caused 468 by a delay spike, it is possible that the acknowledgment for the 469 retransmission arrives back at the sender before the acknowledgments 470 of the original transmissions arrive. If this happens, a possible 471 loss of the original transmission of the data chunk that was 472 retransmitted due to the spurious timeout may remain undetected when 473 applying the F-RTO algorithm. Because the timeout was caused by a 474 delay spike, and it was spurious in that respect, a suitable response 475 is to continue by sending new data. However, if the original 476 transmission was lost, fully reverting the congestion control 477 parameters is too aggressive. Therefore, taking conservative actions 478 on congestion control is recommended, if the SCTP association is 479 multi-homed and retransmissions go to alternative address. The 480 information in duplicate TSNs can be then used for reverting 481 congestion control, if desired [BA04]. 483 Note that the forward transmissions made in F-RTO algorithm step (2b) 484 should be destined to the primary address, since they are not 485 retransmissions. 487 When making a retransmission, a SCTP sender can bundle a number of 488 unacknowledged data chunks and include them in the same packet. This 489 needs to be considered when implementing F-RTO for SCTP. The basic 490 principle of F-RTO still holds: in order to declare the timeout 491 spurious, the sender must get an acknowledgment for a data chunk that 492 was not retransmitted after the retransmission timeout. In other 493 words, acknowledgments of data chunks that were bundled in RTO 494 retransmission must not be used for declaring the timeout spurious. 496 6. Security Considerations 498 The main security threat regarding F-RTO is the possibility of a 499 receiver misleading the sender to set too large a congestion window 500 after an RTO. There are two possible ways a malicious receiver could 501 trigger a wrong output from the F-RTO algorithm. First, the receiver 502 can acknowledge data that it has not received. Second, it can delay 503 acknowledgment of a segment it has received earlier, and acknowledge 504 the segment after the TCP sender has been deluded to enter algorithm 505 step 3. 507 If the receiver acknowledges a segment it has not really received, 508 the sender can be led to declare spurious timeout in F-RTO algorithm 509 step 3. However, since this causes the sender to have incorrect 510 state, it cannot retransmit the segment that has never reached the 511 receiver. Therefore, this attack is unlikely to be useful for the 512 receiver to maliciously gain a larger congestion window. 514 A common case for a retransmission timeout is that a fast 515 retransmission of a segment is lost. If all other segments have been 516 received, the RTO retransmission causes the whole window to be 517 acknowledged at once. This case is recognized in F-RTO algorithm 518 branch (2a). However, if the receiver only acknowledges one segment 519 after receiving the RTO retransmission, and then the rest of the 520 segments, it could cause the timeout to be declared spurious when it 521 is not. Therefore, it is suggested that when an RTO expires during 522 fast recovery phase, the sender would not fully revert the congestion 523 window even if the timeout was declared spurious, but reduce the 524 congestion window to 1. 526 If there are more than one segments missing at the time when a 527 retransmission timeout occurs, the receiver does not benefit from 528 misleading the sender to declare a spurious timeout, because the 529 sender would then have to go through another recovery period to 530 retransmit the missing segments, usually after an RTO has elapsed. 532 7. IANA Considerations 534 This document has no actions for IANA. 536 8. Acknowledgments 538 We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark 539 Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias 540 Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, 541 Samu Kontinen, and Kostas Pentikousis for the discussion and feedback 542 contributed to this text. 544 9. References 546 Normative References 548 [APS99] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 549 Control. RFC 2581, April 1999. 551 [BAFW03] E. Blanton, M. Allman, K. Fall, and L. Wang. A Conservative 552 Selective Acknowledgment (SACK)-based Loss Recovery 553 Algorithm for TCP. RFC 3517, April 2003. 555 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 556 Requirement Levels. RFC 2119, March 1997. 558 [FHG04] S. Floyd, T. Henderson, and A. Gurtov. The NewReno 559 Modification to TCP's Fast Recovery Algorithm. RFC 3782, 560 April 2004. 562 [MMFR96] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP 563 Selective Acknowledgment Options. RFC 2018, October 1996. 565 [PA00] V. Paxson and M. Allman. Computing TCP's Retransmission 566 Timer. RFC 2988, November 2000. 568 [Pos81] J. Postel. Transmission Control Protocol. RFC 793, 569 September 1981. 571 [Ste00] R. Stewart, et. al. Stream Control Transmission Protocol. 572 RFC 2960, October 2000. 574 Informative References 576 [ABF01] M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's 577 Loss Recovery Using Limited Transmit. RFC 3042, January 578 2001. 580 [BA04] E. Blanton and M. Allman. Using TCP Duplicate Selective 581 Acknowledgment (DSACKs) and Stream Control Transmission 582 Protocol (SCTP) Duplicate Transmission Sequence Numbers 583 (TSNs) to Detect Spurious Retransmissions. RFC 3708, 584 February 2004. 586 [BBJ92] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for 587 High Performance. RFC 1323, May 1992. 589 [FMMP00] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An 590 Extension to the Selective Acknowledgment (SACK) Option to 591 TCP. RFC 2883, July 2000. 593 [GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for 594 TCP in a GPRS Network. In Proc. of European Wireless, 595 Florence, Italy, February 2002. 597 [GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in 598 TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, CA, 599 USA, March 2003. 601 [Jac88] V. Jacobson. Congestion Avoidance and Control. In 602 Proceedings of ACM SIGCOMM 88. 604 [LG04] R. Ludwig and A. Gurtov. The Eifel Response Algorithm for 605 TCP. Internet draft 606 "draft-ietf-tsvwg-tcp-eifel-response-05.txt". March 2004. 607 Work in progress. 609 [LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP 610 Robust Against Spurious Retransmissions. ACM SIGCOMM 611 Computer Communication Review, 30(1), January 2000. 613 [LM03] R. Ludwig and M. Meyer. The Eifel Detection Algorithm for 614 TCP. RFC 3522, April 2003. 616 [Nag84] J. Nagle. Congestion Control in IP/TCP Internetworks. RFC 617 896, January 1984. 619 [SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An 620 Enhanced Recovery Algorithm for TCP Retransmission 621 Timeouts. ACM SIGCOMM Computer Communication Review, 33(2), 622 April 2003. 624 [Sar03] P. Sarolahti. Congestion Control on Spurious TCP 625 Retransmission Timeouts. In Proceedings of IEEE Globecom 626 2003, San Francisco, CA, USA. December 2003. 628 [SL03] Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery 629 using SACK option for spurious timeouts. Internet draft 630 "draft-swami-tsvwg-tcp-dclor-02.txt". September 2003. Work 631 in progress. 633 Appendix A: Scenarios 635 This section discusses different scenarios where RTOs occur and how 636 the basic F-RTO algorithm performs in those scenarios. The 637 interesting scenarios are a sudden delay triggering retransmission 638 timeout, loss of a retransmitted packet during fast recovery, link 639 outage causing the loss of several packets, and packet reordering. A 640 performance evaluation with a more thorough analysis on a real 641 implementation of F-RTO is given in [SKR03]. 643 A.1. Sudden delay 645 The main motivation behind the F-RTO algorithm is to improve TCP 646 performance when a delay spike triggers a spurious retransmission 647 timeout. The example below illustrates the segments and 648 acknowledgments transmitted by the TCP end hosts when a spurious 649 timeout occurs, but no packets are lost. For simplicity, delayed 650 acknowledgments are not used in the example. The example below 651 applies the Eifel Response Algorithm [LG04] after detecting a 652 spurious timeout. 654 ... 655 (cwnd = 6, ssthresh < 6, FlightSize = 6) 656 1. <---------------------------- ACK 5 657 2. SEND 10 ----------------------------> 658 (cwnd = 6, ssthresh < 6, FlightSize = 6) 659 3. <---------------------------- ACK 6 660 4. SEND 11 ----------------------------> 661 (cwnd = 6, ssthresh < 6, FlightSize = 6) 662 5. | 663 [delay] 664 | 665 [RTO] 666 [F-RTO step (1)] 667 6. SEND 6 ----------------------------> 668 (cwnd = 6, ssthresh = 3, FlightSize = 6) 669 ---> 670 7. <---------------------------- ACK 7 671 [F-RTO step (2b)] 672 8. SEND 12 ----------------------------> 673 9. SEND 13 ----------------------------> 674 (cwnd = 7, ssthresh = 3, FlightSize = 7) 675 ---> 676 10. <---------------------------- ACK 8 677 [F-RTO step (3b)] 678 [SpuriousRecovery <- SPUR_TO] 679 (cwnd = 7, ssthresh = 6, FlightSize = 6) 680 11. SEND 14 ----------------------------> 681 (cwnd = 7, ssthresh = 6, FlightSize = 7) 682 12. <---------------------------- ACK 9 683 13. SEND 15 ----------------------------> 684 (cwnd = 7, ssthresh = 6, FlightSize = 7) 685 14. <---------------------------- ACK 10 686 15. SEND 16 ----------------------------> 687 (cwnd = 7, ssthresh = 6, FlightSize = 7) 689 ... 691 When a sudden delay long enough to trigger timeout occurs at step 5, 692 the TCP sender retransmits the first unacknowledged segment (step 6). 693 The next ACK covers the RTO retransmission because the originally 694 transmitted segment 6 arrived at the receiver, and the TCP sender 695 continues by sending two new data segments (steps 8, 9). Note that on 696 F-RTO steps (1) and (2b) congestion window and FlightSize are not yet 697 reset, because in case of possible spurious timeout the segments sent 698 before the timeout are still in the network. However, the sender 699 should still be equally aggressive to conventional TCP. Because the 700 second acknowledgment arriving after the RTO retransmission 701 acknowledges data that was not retransmitted due to timeout (step 702 10), the TCP sender declares the timeout as spurious and continues by 703 sending new data on next acknowledgments. Also the congestion control 704 state is reversed, as required by the Eifel Response Algorithm. 706 A.2. Loss of a retransmission 708 If a retransmitted segment is lost, the only way to retransmit it 709 again is to wait for the timeout to trigger the retransmission. Once 710 the segment is successfully received, the receiver usually 711 acknowledges several segments at once, because other segments in the 712 same window have been successfully delivered before the 713 retransmission arrives at the receiver. The example below shows a 714 scenario where retransmission (of segment 6) is lost, as well as a 715 later segment (segment 9) in the same window. The limited transmit 716 [ABF01] or SACK TCP [MMFR96] enhancements are not in use in this 717 example. 719 ... 720 (cwnd = 6, ssthresh < 6, FlightSize = 6) 721 722 723 1. <---------------------------- ACK 5 724 2. SEND 10 ----------------------------> 725 (cwnd = 6, ssthresh < 6, FlightSize = 6) 726 3. <---------------------------- ACK 6 727 4. SEND 11 ----------------------------> 728 (cwnd = 6, ssthresh < 6, FlightSize = 6) 729 5. <---------------------------- ACK 6 730 6. <---------------------------- ACK 6 731 7. <---------------------------- ACK 6 732 8. SEND 6 --------------X 733 (cwnd = 6, ssthresh = 3, FlightSize = 6) 734 735 9. <---------------------------- ACK 6 736 10. SEND 12 ----------------------------> 737 (cwnd = 7, ssthresh = 3, FlightSize = 7) 738 11. <---------------------------- ACK 6 739 12. SEND 13 ----------------------------> 740 (cwnd = 8, ssthresh = 3, FlightSize = 8) 741 [RTO] 742 13. SEND 6 ----------------------------> 743 (cwnd = 8, ssthresh = 2, FlightSize = 8) 744 14. <---------------------------- ACK 9 745 [F-RTO step (2b)] 746 15. SEND 14 ----------------------------> 747 16. SEND 15 ----------------------------> 748 (cwnd = 7, ssthresh = 2, FlightSize = 7) 749 17. <---------------------------- ACK 9 750 [F-RTO step (3a)] 751 [SpuriousRecovery <- FALSE] 752 (cwnd = 3, ssthresh = 2, FlightSize = 7) 753 18. SEND 9 ----------------------------> 754 19. SEND 10 ----------------------------> 755 20. SEND 11 ----------------------------> 756 ... 758 In the example above, segment 6 is lost and the sender retransmits it 759 after three duplicate ACKs in step 8. However, the retransmission is 760 also lost, and the sender has to wait for the RTO to expire before 761 retransmitting it again. Because the first ACK following the RTO 762 retransmission acknowledges the RTO retransmission (step 14), the 763 sender transmits two new segments. The second ACK in step 17 does not 764 acknowledge any previously unacknowledged data. Therefore the F-RTO 765 sender enters the slow start and sets cwnd to 3 * MSS. Congestion 766 window can be set to three segments, because two round-trips have 767 elapsed after the retransmission timeout. After this the receiver 768 acknowledges all segments transmitted prior to entering recovery and 769 the sender can continue transmitting new data in congestion 770 avoidance. 772 A.3. Link outage 774 The example below illustrates the F-RTO behavior when 4 consecutive 775 packets are lost in the network causing the TCP sender to fall back 776 to RTO recovery. Limited transmit and SACK are not used in this 777 example. 779 ... 780 (cwnd = 6, ssthresh < 6, FlightSize = 6) 781 782 1. <---------------------------- ACK 5 783 2. SEND 10 ----------------------------> 784 (cwnd = 6, ssthresh < 6, FlightSize = 6) 785 3. <---------------------------- ACK 6 786 4. SEND 11 ----------------------------> 787 (cwnd = 6, ssthresh < 6, FlightSize = 6) 788 5. <---------------------------- ACK 6 789 | 790 | 791 [RTO] 792 6. SEND 6 ----------------------------> 793 (cwnd = 6, ssthresh = 3, FlightSize = 6) 794 7. <---------------------------- ACK 7 795 [F-RTO step (2b)] 796 8. SEND 12 ----------------------------> 797 9. SEND 13 ----------------------------> 798 (cwnd = 7, ssthresh = 3, FlightSize = 7) 799 10. <---------------------------- ACK 7 800 [F-RTO step (3a)] 801 [SpuriousRecovery <- FALSE] 802 (cwnd = 3, ssthresh = 3, FlightSize = 7) 803 11. SEND 7 ----------------------------> 804 12. SEND 8 ----------------------------> 805 13. SEND 9 ----------------------------> 807 Again, F-RTO sender transmits two new segments (steps 8 and 9) after 808 the RTO retransmission is acknowledged. Because the next ACK does not 809 acknowledge any data that was not retransmitted after the 810 retransmission timeout (step 10), the F-RTO sender proceeds with 811 conventional recovery and slow start retransmissions. 813 A.4. Packet reordering 815 Since F-RTO modifies the TCP sender behavior only after a 816 retransmission timeout and it is intended to avoid unnecessary 817 retransmissions only after spurious timeout, we limit the discussion 818 on the effects of packet reordering in F-RTO behavior to the cases 819 where packet reordering occurs immediately after the retransmission 820 timeout. When the TCP receiver gets an out-of-order segment, it 821 generates a duplicate ACK. If the TCP sender implements the basic 822 F-RTO algorithm, this may prevent the sender from detecting a 823 spurious timeout. 825 However, if the TCP sender applies the SACK-enhanced F-RTO, it is 826 possible to detect a spurious timeout also when packet reordering 827 occurs. We illustrate the behavior of SACK-enhanced F-RTO below when 828 segment 8 arrives before segments 6 and 7, and segments starting from 829 segment 6 are delayed in the network. In this example the TCP sender 830 reduces the congestion window and slow start threshold in response to 831 spurious timeout. 833 ... 834 (cwnd = 6, ssthresh < 6, FlightSize = 6) 835 1. <---------------------------- ACK 5 836 2. SEND 10 ----------------------------> 837 (cwnd = 6, ssthresh < 6, FlightSize = 6) 838 3. <---------------------------- ACK 6 839 4. SEND 11 ----------------------------> 840 5. | 841 [delay] 842 | 843 [RTO] 844 6. SEND 6 ----------------------------> 845 (cwnd = 6, ssthresh = 3, FlightSize = 6) 846 ---> 847 7. <---------------------------- ACK 6 848 [SACK 8] 849 [SACK F-RTO stays in step 2] 850 8. ---> 851 9. <---------------------------- ACK 7 852 [SACK 8] 853 [SACK F-RTO step (2b)] 854 10. SEND 12 ----------------------------> 855 11. SEND 13 ----------------------------> 856 (cwnd = 7, ssthresh = 3, FlightSize = 7) 857 12. ---> 858 13. <---------------------------- ACK 9 859 [SACK F-RTO step (3b)] 860 [SpuriousRecovery <- SPUR_TO] 861 (cwnd = 7, ssthresh = 6, FlightSize = 6) 862 14. SEND 14 ----------------------------> 863 (cwnd = 7, ssthresh = 6, FlightSize = 7) 864 15. <---------------------------- ACK 10 865 16. SEND 15 ----------------------------> 866 ... 868 After RTO expires and the sender retransmits segment 6 (step 6), the 869 receiver gets segment 8 and generates duplicate ACK with SACK for 870 segment 8. In response to the acknowledgment the TCP sender does not 871 send anything but stays in F-RTO step 2. Because the next 872 acknowledgment advances the cumulative ACK point (step 9), the sender 873 can transmit two new segments according to SACK-enhanced F-RTO. The 874 next segment acknowledges new data between 7 and 11 that was not 875 acknowledged earlier (segment 7), so the F-RTO sender declares the 876 timeout spurious. 878 Appendix B: SACK-enhanced F-RTO and Fast Recovery 879 We believe that slightly modified SACK-enhanced F-RTO algorithm can 880 be used to detect spurious timeouts also when RTO expires while an 881 earlier loss recovery is underway. However, there are issues that 882 need to be considered if F-RTO is applied in this case. 884 The original SACK-based F-RTO requires in algorithm step 3 that an 885 ACK acknowledges previously unacknowledged non-retransmitted data 886 between SND.UNA and send_high. If RTO expires during earlier 887 (SACK-based) loss recovery, the F-RTO sender must only use 888 acknowledgments for non-retransmitted segments transmitted before the 889 SACK-based loss recovery started. This means that in order to declare 890 timeout spurious the TCP sender must receive an acknowledgment for 891 non-retransmitted segment between SND.UNA and RecoveryPoint in 892 algorithm step 3. RecoveryPoint is defined in conservative 893 SACK-recovery algorithm [BAFW03], and it is set to indicate the 894 highest segment transmitted so far when SACK-based loss recovery 895 begins. In other words, if the TCP sender receives acknowledgment for 896 segment that was transmitted more than one RTO ago, it can declare 897 the timeout spurious. Defining an efficient algorithm for checking 898 these conditions remains as a future work item. 900 When spurious timeout is detected according to the rules given above, 901 it may be possible that the response algorithm needs to consider this 902 case separately, for example in terms of what segments to retransmit 903 after RTO expires, and whether it is safe to revert the congestion 904 control parameters in this case. This is considered as a topic of 905 future research. 907 Appendix C: Discussion on Window Limited Cases 909 When the advertised window limits the transmission of two new 910 previously unsent segments, or there are no new data to send, it was 911 recommended in F-RTO algorithm step (2b) that the TCP sender would 912 continue with conventional RTO recovery algorithm. The disadvantage 913 of doing this is that the sender may continue unnecessary 914 retransmissions due to possible spurious timeout. This section 915 briefly discusses the options that can potentially result in better 916 performance when transmitting previously unsent data is not possible. 918 - The TCP sender could reserve an unused space of a size of one or 919 two segments in the advertised window to ensure the use of 920 algorithms such as F-RTO or Limited Transmit [ABF01] in window 921 limited situations. On the other hand, while doing this, the TCP 922 sender should ensure that the window of outstanding segments is 923 large enough to have a proper utilization of the available pipe. 925 - Use additional information if available, e.g. TCP timestamps with 926 the Eifel Detection algorithm, for detecting a spurious timeout. 928 However, Eifel detection may yield different results from F-RTO 929 when ACK losses and a RTO occur within the same round-trip time 930 [SKR03]. 932 - Retransmit data from the tail of the retransmission queue and 933 continue with step 3 of the F-RTO algorithm. It is possible that 934 the retransmission is unnecessarily made, hence this option is not 935 encouraged, except for hosts that are known to operate in an 936 environment that is highly likely to have spurious timeouts. On the 937 other hand, with this method it is possible to avoid several 938 unnecessary retransmissions due to spurious timeout by doing only 939 one retransmission that may be unnecessary. 941 - Send a zero-sized segment below SND.UNA similar to TCP Keep-Alive 942 probe and continue with step 3 of the F-RTO algorithm. Since the 943 receiver replies with a duplicate ACK, the sender is able to detect 944 from the incoming acknowledgment whether the timeout was spurious. 945 While this method does not send data unnecessarily, it delays the 946 recovery by one round-trip time in cases where the timeout was not 947 spurious, and therefore is not encouraged. 949 - In receiver-limited cases, send one octet of new data regardless of 950 the advertised window limit, and continue with step 3 of the F-RTO 951 algorithm. It is possible that the receiver has free buffer space 952 to receive the data by the time the segment has propagated through 953 the network, in which case no harm is done. If the receiver is not 954 capable of receiving the segment, it rejects the segment and sends 955 a duplicate ACK. 957 Authors' Addresses 959 Pasi Sarolahti 960 Nokia Research Center 961 P.O. Box 407 962 FIN-00045 NOKIA GROUP 963 Finland 965 Phone: +358 50 4876607 966 EMail: pasi.sarolahti@nokia.com 967 http://www.cs.helsinki.fi/u/sarolaht/ 969 Markku Kojo 970 University of Helsinki 971 Department of Computer Science 972 P.O. Box 26 973 FIN-00014 UNIVERSITY OF HELSINKI 974 Finland 975 Phone: +358 9 1914 4179 976 EMail: markku.kojo@cs.helsinki.fi 978 Full Copyright Statement 980 Copyright (C) The Internet Society (2004). This document is subject 981 to the rights, licenses and restrictions contained in BCP 78, and 982 except as set forth therein, the authors retain all their rights. 984 This document and the information contained herein are provided on an 985 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 986 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 987 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 988 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 989 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 990 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 992 Intellectual Property 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Acknowledgement 1018 Funding for the RFC Editor function is currently provided by the 1019 Internet Society.