idnits 2.17.1 draft-jarvinen-tcpm-sack-recovery-entry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 258 has weird spacing: '... is the case ...' -- The document date (5 March 2009) is 5503 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2883' is defined on line 548, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) -- Duplicate reference: RFC2581, mentioned in 'RFC2581bis', was also mentioned in 'RFC2581'. ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) == Outdated reference: A later version (-06) exists of draft-floyd-tcpm-ackcc-04 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 3782 (Obsoleted by RFC 6582) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force I. Jarvinen 2 INTERNET-DRAFT M. Kojo 3 draft-jarvinen-tcpm-sack-recovery-entry-00.txt University of Helsinki 4 Intended status: Standards Track 5 March 2009 5 Expires: September 2009 7 Using TCP Selective Acknowledgement (SACK) Information to Determine 8 Duplicate Acknowledgements for Loss Recovery Initiation 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Abstract 46 This document describes a TCP sender algorithm to trigger loss 47 recovery based on the information gathered on a SACK scoreboard 48 instead of simply counting the number of arriving duplicate 49 acknowledgements in the traditional way. The given algorithm is more 50 robust to ACK losses, ACK reordering, missed duplicate 51 acknowledgements due to delayed acknowledgements, and extra 52 duplicate acknowledgements due to duplicated segments and out-of- 53 window segments. The algorithm allows not only a timely initiation 54 of TCP loss recovery but also reduces false fast retransmits. It 55 has a low implementation cost on top of the SACK scoreboard defined 56 in RFC 3517. 58 Table of Contents 60 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 4 62 1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Algorithm Details . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Small Segment Sender . . . . . . . . . . . . . . . . . . 6 66 3.2. Third Segment after a Hole is Small. . . . . . . . . . . 7 67 3.3. SACK Capability Misbehavior. . . . . . . . . . . . . . . 7 68 3.4. Compatibility with Duplicate ACK based Loss 69 Recovery Algorithms . . . . . . . . . . . . . . . . . . . . . 7 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 8 73 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 A. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 A.1. Basic Case . . . . . . . . . . . . . . . . . . . . . . . 9 76 A.2. Delayed ACK. . . . . . . . . . . . . . . . . . . . . . . 10 77 A.3. ACK Losses . . . . . . . . . . . . . . . . . . . . . . . 11 78 A.4. ACK Reordering . . . . . . . . . . . . . . . . . . . . . 11 79 A.5. Packet Duplication . . . . . . . . . . . . . . . . . . . 12 80 A.6. Mitigation of Blind Throughput Reduction 81 Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Normative References . . . . . . . . . . . . . . . . . . . . . . 13 84 Informative References . . . . . . . . . . . . . . . . . . . . . 13 85 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The Transmission Control Protocol (TCP) [RFC793] has two methods for 90 triggering retransmissions. First, the TCP sender relies on 91 incoming duplicate acknowledgement (ACKs) [RFC2581bis], indicating 92 receipt of out-of-order segments at the TCP receiver. After 93 receiving a required number of duplicate ACKs (usually three), the 94 TCP sender retransmits the first unacknowledged segment and 95 continues with a fast recovery algorithm such as Reno [RFC2581], 96 NewReno [RFC3782] or SACK-based loss recovery [RFC3517]. Second, 97 the TCP sender maintains a retransmission timer that triggers 98 retransmission of segments, if the retransmission timer expires 99 before the segments have been acknowledged. 101 While the conservative loss recovery algorithm defined in [RFC3517] 102 takes full advantage of SACK information during a loss recovery, it 103 does not consider the very same information during the pre-recovery 104 detection phase. Instead, it simply counts the number of arriving 105 duplicate ACKs and leans on the number of duplicate ACKs in deciding 106 when to enter loss recovery. However, this traditional heuristics of 107 simply counting the number of duplicate ACKs to trigger a loss 108 recovery fails in several cases to determine correctly the actual 109 number of valid out-of-order segments the receiver has successfully 110 received. First, trusting on duplicate ACKs alone utterly fails to 111 get hold of the whole picture in case of ACK losses and ACK 112 reordering, resulting in delayed or missed initiation of fast 113 retransmit and fast recovery. Similarly, the delayed ACK mechanism 114 tends to conceal the first duplicate ACK as the delayed cumulative 115 ACK becomes combined with the first duplicate ACK when the first 116 out-of-order segment arrives at the receiver (in case of an enlarged 117 ACK ratio such as with ACK congestion control [FARI08], even more 118 significant portion is affected). Second, segment duplication or 119 out-of-window segments increase the risk of falsely triggering loss 120 recovery as they trigger duplicate ACKs. 122 The algorithm specified in this document uses TCP Selective 123 Acknowledgement Option [RFC2018] to determine duplicate ACKs and to 124 trigger loss recovery based on the information gathered on the SACK 125 scoreboard [RFC3517]. It works in the pre-recovery state giving a 126 more accurate heurestic for determining the number of out-of-order 127 segments arrived at the TCP receiver. The information gathered on 128 the scoreboard reveals missing ACKs and allows detecting duplicate 129 events. Therefore, the algorithm enables a timely triggering of Fast 130 Retransmit. In addition, it allows the use of Limited Transmit 131 regardless of lost ACKs and also in the cases where the SACK 132 information is piggybacked to a cumulative ACK due to delayed ACKs. 133 This, in turn, allows keeping ACK clock running more accurately. 135 This algorithm is close to what Linux TCP implementation has used 136 for a very long time. A similar approach is briefly mentioned along 137 ACK congestion control [FARI08] but as the usefulness of the 138 algorithm in this document is more general and not limited to ACK 139 congestion control we specify it separately. We also note that the 140 defination of a duplicate acknowledgement already suggests that an 141 incoming ACK can be considered as a duplicate ACK if it "contains 142 previously unknown SACK information" [RFC2581bis]. 144 1.1. Conventions and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in BCP 14, RFC 2119 149 [RFC2119] and indicate requirement levels for protocols. 151 1.2. Definitions 153 The reader is expected to be familiar with the definitions given in 154 [RFC2581bis], [RFC2018], and [RFC3517]. 156 2. Algorithm Details 158 In order to use this algorithm, a TCP sender MUST have TCP Selective 159 Acknowledgement Option [RFC2018] enabled and negotiated for the TCP 160 connection. A TCP sender MUST maintain SACK information in an 161 approproate data structure such as scoreboard defined in [RFC3517]. 162 This algorithm uses functions IsLost (SeqNum), Update(), and SetPipe 163 () and variables DupThresh, HighData, HighRxt, Pipe, and 164 RecoveryPoint, as defined in [RFC3517]. 166 A TCP sender using this algorithm MUST take following steps: 168 1) Upon the receipt of any ACK containing SACK information: 170 If no previous loss event has occurred on the connection OR 171 RecoveryPoint is less than SND.UNA (the oldest unacknowledged 172 sequence number [RFC793]), continue with the other steps of this 173 algorithm. Otherwise, continue the ongoing loss recovery. 175 2) Update the scoreboard via the Update () function as outlined in 176 [RFC3517]. 178 3) Determinate if a loss recovery should be initiated: 180 If IsLost(SND.UNA) returns false, goto step 4A. Otherwise goto 181 step 4B. 183 4A) Invoke optional Limited Transmit: 185 Set HighRxt to SND.UNA and run SetPipe(). The TCP sender MAY 186 transmit previously unsent data segments according the 187 guidelines of Limited Transmit [RFC3042], with the exception 188 that the amount of octets that can be send is determined by Pipe 189 and cwnd. 191 If cwnd - pipe >= 1 SMSS, the TCP sender can transmit one or 192 more segments as follows: 194 Send Loop: 196 a) If available unsent data exists and the receiver's advertised 197 window allows, transmit one segment of up to SMSS octets of 198 previously unsent data starting with sequence number 199 HighData+1 and update HighData to reflect the transmission of 200 the data segment. Otherwise, exit Send Loop. 202 b) Run SetPipe() to re-calculate the number of outstanding 203 octets in the network. If cwnd - pipe >= 1 SMSS, go to step 204 a) of Send Loop. Otherwise, exit Send Loop. 206 4B) Invoke Fast Retransmit and enter loss recovery: 208 Initiate a loss recovery phase, per the fast retransmit 209 algorithm outlined in [RFC2581] and continue with a fast 210 recovery algorithm, such as the SACK-based loss recovery 211 algorithm outlined in [RFC3517]. 213 3. Discussion 215 In scenarios where no ACK losses nor reordering occur and the first 216 acknowledgement with SACK information is not the ACK held due to 217 delayed acknowledgements mechanism, the new SACK information with 218 each duplicate ACK covers a single segment. In such a case, this 219 algorithm will trigger loss recovery after three duplicate 220 acknowledgements and will allow transmission of a single new segment 221 using Limited Transmit on each acknowledgement. This is identical 222 to the behavior that would occur without this algorithm (assuming 223 DupThresh is 3 and that all segments are SMSS sized). This scenario 224 together with other scenarios describing the behavior of the 225 algorithm are depicted in Appendix A. 227 A set of potential issues to consider with the algorithm are 228 discussed in the following. 230 3.1. Small Segment Sender 232 If a TCP sender is sending small segments (usually intentionally 233 overriding Nagle algorithm [RFC896]), the IsLost(SND.UNA) used in 234 step 3 of the algorithm might fail to detect the need for loss 235 recovery on the third duplicate acknowledgement because not enough 236 octets have been sacked to cover DupThresh * SMSS bytes above 237 SND.UNA. If the SACKed octects are discontiguous (the second rule of 238 IsLost()), the loss recovery is still triggered on time. Otherwise, 239 the loss recovery is delayed, either until enough additional octets 240 are SACKed later or until RTO is triggered. 242 If such a concern exists, a TCP sender MAY compare, in parallel to 243 the check given by this algorithm, the number of duplicate ACKs to 244 DupThresh to trigger loss recovery on time. However, some robustness 245 of this algorithm is lost. In any case, such a solution is likely to 246 just postpone the problem since the very same IsLost() gets used 247 later during the SACK-based loss recovery [RFC3517]. 249 A TCP sender with fully packet based scoreboard is able to discern 250 the packet boundaries with precision higher to SMSS heurestics 251 (e.g., in Linux TCP), and thus can consider full segments in 252 IsLost() regardless of SMSS. Therefore, a TCP sender can avoid the 253 problem with small segments both with this algorithm and with loss 254 recovery given in [RFC3517]. 256 3.2. Third Segment after a Hole is Small 258 A variant of small segment sender case is the case where only the 259 third (last) segment after the hole is smaller than SMSS. It would 260 be possible to detect this case by modifying IsLost() function. 262 3.3. SACK Capability Misbehavior 264 If the receiver represents such a SACK misbehavior that it 265 advertizes SACK capability but never sends any SACK blocks when it 266 should, this algorithm fails to enter loss recovery and 267 retransmission timeout is required for recovery. However, such 268 misbehavior does not allow SACK-based loss recovery [RFC3517] to 269 work either, and a TCP sender will anyway require a timeout to 270 recover. 272 3.4. Compatibility with Duplicate ACK based Loss Recovery Algorithms 274 This algorithm SHOULD NOT be used together with a fast recovery 275 algorithm that determines the segments that have left the network 276 based on the number of arriving duplicate acknowledgements (e.g., 277 NewReno [RFC3782]), instead of the actual segments reported by SACK. 278 In presence of ACK reordering such an algorithm will count the 279 delayed duplicate acknowledgements during the fast recovery 280 algorithm as extra while detemining the number of packets that have 281 left the network. 283 In general there should be very little reason to combine this 284 algorithm with a loss recovery algorithm that is based on inferior, 285 non-SACK based information only. 287 4. Security Considerations 289 A malicious TCP receiver may send false SACK information for 290 sequence number ranges which it has not received in order to trigger 291 Fast Retransmit sooner. Such behavior would only be useful when out- 292 of-order segments have arrived because otherwise the flow undergoes 293 a loss recovery with a window reduction. This kind of lying involves 294 guessing which segments will arrive later. In case the guess was 295 wrong, the performance of the flow is ruined because the TCP sender 296 will need a retransmission timeout as it will not retransmit the 297 segments until it assumes SACK reneging. On a successful guess the 298 attacker is able to trigger the recovery slightly earlier. The later 299 segments would have allowed reporting the very same regions with 300 SACK anyway. Therefore, the gain from this attack is small, hardly 301 justifiable considering the drastic effect of a misguess. Also, a 302 similar attack can be made with the duplicate acknowledgment based 303 algorithm (even if the new SACK information rule is applied) by 304 sending false duplicate acknowledgements with false SACK ranges, and 305 trivially without the new SACK information rule. 307 A variation of the lying attack discards reliability of the flow but 308 as soon as the reliability is not a concern of the receiver, a 309 number of simpler ways exists to attacked TCP independently of this 310 algorithm. Thus this algorithm is not considered to weaken TCP 311 security properties against false information. 313 5. IANA Considerations 315 This document has no actions for IANA. 317 6. Acknowledgements 319 Appendix 320 A. Scenarios 322 A.1. Basic Case 324 In this scenario no Delayed ACK, ACK losses, reordering or other 325 "abnormal" behavior happens. For simplicity all the segments are 326 SMSS sized. 328 Once the TCP receiver gets first out-of-order segment, it sends a 329 duplicate ACK with SACK information about the received octets. The 330 following two out-of-order segments trigger a duplicate ACK each, 331 with the corresponding range SACKed in addition to the previously 332 know information. The sender gets those duplicate ACKs in-order, 333 each of them will SACK a new previously unknown segment. 335 This algorithm triggers loss recovery on third duplicate ACK because 336 IsLost returns true as DupThresh * SMSS bytes became SACKed above 337 the SND.UNA on the same acknowledgement, thus the behavior is 338 identical to that of a sender which is using duplicate 339 acknowledgments. If Limited Transmit is in use, two first duplicate 340 ACKs allow a single segment to be sent with either of the algorithms 341 (Pipe is decremented by SMSS by the SACKed octets per ACK allowing 342 SMSS worth of new octets). 344 ACK Transmitted Received ACK Sent 345 Received Segment Segment (Including SACK Blocks) 347 1000 348 3000-3499 3000-3499 (delayed ACK) 349 3500-3999 3500-3999 4000 350 2000 351 4000-4499 (dropped) 352 4500-4999 4500-4999 4000, SACK=4500-5000 353 3000 354 5000-5499 5000-5499 4000, SACK=4500-5500 355 5500-5999 5500-5999 4000, SACK=4500-6000 356 4000 357 6000-6499 6000-6499 4000, SACK=4500-6500 358 6500-6999 6500-6999 4000, SACK=4500-7000 359 4000, SACK=4500-5000 360 7000-7499 7000-7499 4000, SACK=4500-7500 361 4000, SACK=4500-5500 362 7500-7999 7500-7999 4000, SACK=4500-8000 363 4000, SACK=4500-6000 364 4000-4499 4000-4499 8000 365 4000, SACK=4500-6500 367 A.2. Delayed ACK 369 A basic case with delayed ACK send the first ACK with SACK 370 information but since the previous ACK was sent with a lower 371 sequence number because an acknowledgment is held by delayed ACK, 372 the sender will not considered it as duplicate ACK. Because the 373 segment contains SACK information that is identical to the basic 374 case, the sender can use Limited Transmit with the same segments as 375 in the basic case and will start loss recovery at the third 376 acknowledgment, i.e., with the second duplicate acknowledgment. In 377 the same situation the duplicate ACK based sender will have to wait 378 for one more duplicate ACK to arrive to do the same as the first 379 acknowledgment is fully "wasted". 381 Technically an acknowledgement with a sequence number higher than 382 what was previously acknowledged is not a duplicate acknowledgement 383 but a presence of the SACK block tells another story revealing the 384 receiver which used delayed ACK, and thus the missing duplicate 385 acknowledgement in between. The response of a TCP sender taking 386 advantage of such inferred duplicate acknowledgements is well within 387 the guidelines of packet conservation principle [Jac88] as it still 388 sends only when segments have left the network. 390 ACK Transmitted Received ACK Sent 391 Received Segment Segment (Including SACK Blocks) 393 1500 394 3000-3499 3000-3499 3500 395 3500-3999 3500-3999 (delayed ACK) 396 2500 397 4000-4499 (dropped) 398 4500-4999 4500-4999 4000, SACK=4500-5000 399 3500 400 5000-5499 5000-5499 4000, SACK=4500-5500 401 5500-5999 5500-5999 4000, SACK=4500-6000 402 4000, SACK=4500-5000 403 6000-6499 6000-6499 4000, SACK=4500-6500 404 6500-6999 6500-6999 4000, SACK=4500-7000 405 4000, SACK=4500-5500 406 7000-7499 7000-7499 4000, SACK=4500-7500 407 4000, SACK=4500-60000 408 4000-4499 4000-4499 7500 409 4000, SACK=4500-6500 411 A.3. ACK Losses 413 This case with ACK loss shares much behavior with the case with 414 delayed ACK. If hole at rcv.nxt is filled, the sender will notice 415 that cumulative ACK advanced. In case of out-of-order segments the 416 first ACK which gets through to the sender includes SACK blocks up 417 to the quantity the SACK block redundancy is able to cover. With 418 this algorithm the sender immediately takes use of all the 419 information that is made available by the incoming ACK. 421 ACK Transmitted Received ACK Sent 422 Received Segment Segment (Including SACK Blocks) 424 1000 425 3000-3499 3000-3499 (delayed ACK) 426 3500-3999 3500-3999 4000 427 2000 428 4000-4499 (dropped) 429 4500-4999 4500-4999 4000, SACK=4500-5000 430 (dropped) 431 3000 432 5000-5499 5000-5499 4000, SACK=4500-5500 433 5500-5999 5500-5999 4000, SACK=4500-6000 434 4000 435 6000-6499 6000-6499 4000, SACK=4500-6500 436 6500-6999 6500-6999 4000, SACK=4500-7000 437 4000, SACK=4500-5500 (two segments left the network) 438 7000-7499 7000-7499 4000, SACK=4500-7500 439 7500-7999 7500-7999 4000, SACK=4500-8000 440 4000, SACK=4500-6000 441 4000-4499 4000-4499 8000 442 4000, SACK=4500-6500 444 A.4. ACK Reordering 446 With ACK reordering an ACK is postponed. Due to redundancy the next 447 ACK after postponed one contains not only its own information but 448 also the information of the reordered ACK (similar to the ACK losses 449 case). Then when the reordered ACK arrives, the sender already knows 450 about the information it provides and therefore no actions are taken 451 with this algorithm. 453 ACK Transmitted Received ACK Sent 454 Received Segment Segment (Including SACK Blocks) 456 1000 457 3000-3499 3000-3499 (delayed ACK) 458 3500-3999 3500-3999 4000 459 2000 460 4000-4499 (dropped) 461 4500-4999 4500-4999 4000, SACK=4500-5000 462 (delayed) 463 3000 464 5000-5499 5000-5499 4000, SACK=4500-5500 465 5500-5999 5500-5999 4000, SACK=4500-6000 466 4000 467 6000-6499 6000-6499 4000, SACK=4500-6500 468 6500-6999 6500-6999 4000, SACK=4500-7000 469 4000, SACK=4500-5500 470 7000-7499 7000-7499 4000, SACK=4500-7500 471 7500-7999 7500-7999 4000, SACK=4500-8000 472 4000, SACK=4500-5000 (has only redundant information) 473 4000, SACK=4500-6000 474 4000-4499 4000-4499 8000 475 4000, SACK=4500-6500 477 A.5. Packet Duplication 479 Packet duplication happens either due to unnecessary retransmission 480 or hardware duplication. It adds a redundant ACK which has only 481 redundant information or a data segment to the stream which will 482 triggers a redundant duplicate ACK (possibly with SACK and/or DSACK 483 information). Because neither adds any new SACKed octets at the 484 sender, this algorithm will not do anything while duplicate ACK 485 based receiver would falsely consider it as a duplicate ACK. 487 If one of the redundant ACKs is lost, the effect of duplication is 488 just negated. 490 It is possible for the sender to detect this case using DSACK alone. 492 A.6. Mitigation of Blind Throughput Reduction Attack 494 In case an attacker knows or is able to guess 4-tuple of a TCP 495 connection, it may apply a blind throughput reduction attack. In 496 this attack TCP is tricked to send duplicate ACK to the other 497 endpoint using out-of-window segments which it is considerably 498 easier to achieve than a match with sequence numbers. If more than 499 dupThresh duplicate ACKs can be triggered in row without any 500 legimate segment that advances acknowledged sequence number, the 501 other end acts according that false congestion signal and halves the 502 window. 504 With this algorithm such duplicate ACKs are filtered because they do 505 not have any new in-window SACK blocks (DSACK might be present 506 though). 508 References 510 Normative References 512 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 513 793, September 1981. 515 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, 516 "TCP Selective Acknowledgment Options", RFC 2018, 517 October 1996. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 523 Control", RFC 2581, April 1999. 525 [RFC2581bis] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 526 Control", RFC 2581bis, April 2008. 528 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 529 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 530 January 2001. 532 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, 533 "A Conservative Selective Acknowledgment (SACK)-based 534 Loss Recovery Algorithm for TCP", RFC 3517, April 2003. 536 Informative References 538 [FARI08] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, Adding 539 Acknowledgement Congestion Control to TCP, Internet-Draft, 540 draft-floyd-tcpm-ackcc-04, July 2008. 542 [Jac88] Jacobson, V., "Congestion Avoidance and Control", In 543 Proc. ACM SIGCOMM 88. 545 [RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 546 RFC 896, January 1984. 548 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 549 Extension to the Selective Acknowledgement (SACK) Option 550 for TCP", RFC 2883, July 2000. 552 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 553 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 554 April 2004. 556 AUTHORS' ADDRESSES 558 Ilpo Jarvinen 559 University of Helsinki 560 P.O. Box 68 561 FI-00014 UNIVERSITY OF HELSINKI 562 Finland 563 Email: ilpo.jarvinen@helsinki.fi 565 Markku Kojo 566 University of Helsinki 567 P.O. Box 68 568 FI-00014 UNIVERSITY OF HELSINKI 569 Finland 570 Email: kojo@cs.helsinki.fi