idnits 2.17.1 draft-jarvinen-tcpm-sack-recovery-entry-01.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 -- The document date (5 August 2009) is 5378 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) ** 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) -- 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 (~~), 1 warning (==), 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-01.txt University of Helsinki 4 Intended status: Standards Track 5 August 2009 5 Expires: February 2010 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 February 2010. 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. . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 5 62 1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 6 63 2. Algorithm Details . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Small Segment Sender . . . . . . . . . . . . . . . . . . 7 66 3.2. One Segment is Small . . . . . . . . . . . . . . . . . . 8 67 3.3. SACK Capability Misbehavior. . . . . . . . . . . . . . . 8 68 3.4. Compatibility with Duplicate ACK based Loss 69 Recovery Algorithms . . . . . . . . . . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 10 73 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 A. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 A.1. Basic Case . . . . . . . . . . . . . . . . . . . . . . . 10 76 A.2. Delayed ACK. . . . . . . . . . . . . . . . . . . . . . . 11 77 A.3. ACK Losses . . . . . . . . . . . . . . . . . . . . . . . 12 78 A.4. ACK Reordering . . . . . . . . . . . . . . . . . . . . . 12 79 A.5. Packet Duplication . . . . . . . . . . . . . . . . . . . 13 80 A.6. Mitigation of Blind Throughput Reduction 81 Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Normative References . . . . . . . . . . . . . . . . . . . . . . 14 84 Informative References . . . . . . . . . . . . . . . . . . . . . 14 85 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 15 86 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 88 Changes from draft-jarvinen-tcpm-sack-recovery-entry-00.txt 90 * TODO items embedded: Improvements with window update, clarify 91 dupack counting 93 * Modified ACK reordering scenario in appendix, shows now a scenario 94 where recovery is triggered in a more timely manner. 96 * IDnits 98 * Handle small segments case using duplicate ACKs counter paraller 99 to the SACK blocks based detection. 101 * Add a placeholder for SACK splitting 103 * Mentioned FACK as some ideas are inherited from there 105 END OF SECTION TO BE DELETED. 107 1. Introduction 109 The Transmission Control Protocol (TCP) [RFC793] has two methods for 110 triggering retransmissions. First, the TCP sender relies on 111 incoming duplicate acknowledgement (ACKs) [RFC2581bis], indicating 112 receipt of out-of-order segments at the TCP receiver. After 113 receiving a required number of duplicate ACKs (usually three), the 114 TCP sender retransmits the first unacknowledged segment and 115 continues with a fast recovery algorithm such as Reno [RFC2581], 116 NewReno [RFC3782] or SACK-based loss recovery [RFC3517]. Second, 117 the TCP sender maintains a retransmission timer that triggers 118 retransmission of segments, if the retransmission timer expires 119 before the segments have been acknowledged. 121 While the conservative loss recovery algorithm defined in [RFC3517] 122 takes full advantage of SACK information during a loss recovery, it 123 does not consider the very same information during the pre-recovery 124 detection phase. Instead, it simply counts the number of arriving 125 duplicate ACKs and leans on the number of duplicate ACKs in deciding 126 when to enter loss recovery. However, this traditional heuristics of 127 simply counting the number of duplicate ACKs to trigger a loss 128 recovery fails in several cases to determine correctly the actual 129 number of valid out-of-order segments the receiver has successfully 130 received. First, trusting on duplicate ACKs alone utterly fails to 131 get hold of the whole picture in case of ACK losses and ACK 132 reordering, resulting in delayed or missed initiation of fast 133 retransmit and fast recovery. Similarly, the delayed ACK mechanism 134 tends to conceal the first duplicate ACK as the delayed cumulative 135 ACK becomes combined with the first duplicate ACK when the first 136 out-of-order segment arrives at the receiver (in case of an enlarged 137 ACK ratio such as with ACK congestion control [FARI08], even more 138 significant portion is affected). Second, segment duplication or 139 out-of-window segments increase the risk of falsely triggering loss 140 recovery as they trigger duplicate ACKs. 142 ADDME: window updates can be used to determine current state when 143 other ACKs where lost, they would not even be dupacks (Thanks to 144 corridor talk with Anna Brunstrom). 146 The algorithm specified in this document uses TCP Selective 147 Acknowledgement Option [RFC2018] to determine duplicate ACKs and to 148 trigger loss recovery based on the information gathered on the SACK 149 scoreboard [RFC3517]. It works in the pre-recovery state giving a 150 more accurate heurestic for determining the number of out-of-order 151 segments arrived at the TCP receiver. The information gathered on 152 the scoreboard reveals missing ACKs and allows detecting duplicate 153 events. Therefore, the algorithm enables a timely triggering of Fast 154 Retransmit. In addition, it allows the use of Limited Transmit 155 regardless of lost ACKs and also in the cases where the SACK 156 information is piggybacked to a cumulative ACK due to delayed ACKs. 157 This, in turn, allows keeping ACK clock running more accurately. 159 This algorithm is close to what Linux TCP implementation has used 160 for a very long time. A similar approach is briefly mentioned along 161 ACK congestion control [FARI08] but as the usefulness of the 162 algorithm in this document is more general and not limited to ACK 163 congestion control we specify it separately. We also note that the 164 defination of a duplicate acknowledgement already suggests that an 165 incoming ACK can be considered as a duplicate ACK if it "contains 166 previously unknown SACK information" [RFC2581bis]. While 167 similarities with this algorithm and Forward Acknowledgement (FACK) 168 [MM96] exist, they differ in how the quantity of data outstanding in 169 the network is determined. 171 1.1. Conventions and Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in BCP 14, RFC 2119 176 [RFC2119] and indicate requirement levels for protocols. 178 1.2. Definitions 180 The reader is expected to be familiar with the definitions given in 181 [RFC2581bis], [RFC2018], and [RFC3517]. 183 2. Algorithm Details 185 In order to use this algorithm, a TCP sender MUST have TCP Selective 186 Acknowledgement Option [RFC2018] enabled and negotiated for the TCP 187 connection. A TCP sender MUST maintain SACK information in an 188 approproate data structure such as scoreboard defined in [RFC3517]. 189 This algorithm uses functions IsLost (SeqNum), Update(), and SetPipe 190 () and variables DupThresh, HighData, HighRxt, Pipe, and 191 RecoveryPoint, as defined in [RFC3517]. 193 A TCP sender using this algorithm MUST take following steps: 195 1) Upon the receipt of any ACK containing SACK information: 197 If no previous loss event has occurred on the connection OR 198 RecoveryPoint is less than SND.UNA (the oldest unacknowledged 199 sequence number [RFC793]), continue with the other steps of this 200 algorithm. Otherwise, continue the ongoing loss recovery. 202 2) Update the scoreboard via the Update () function as outlined in 203 [RFC3517]. 205 3) Only if SACK blocks contained previously unknown in-window SACK 206 information, count the acknowledgment as duplicate ACK 207 [RFC2581bis]. TODO: clarify how to behave on cumulative ACKs 208 and with non-dupacks. 210 4) Determinate if a loss recovery should be initiated: 212 If IsLost(SND.UNA) returns false AND the sender has received 213 less than DupThresh duplicate ACKs, goto step 5A. Otherwise goto 214 step 5B. 216 5A) Invoke optional Limited Transmit: 218 Set HighRxt to SND.UNA and run SetPipe(). The TCP sender MAY 219 transmit previously unsent data segments according the 220 guidelines of Limited Transmit [RFC3042], with the exception 221 that the amount of octets that can be send is determined by Pipe 222 and cwnd. 224 If cwnd - pipe >= 1 SMSS, the TCP sender can transmit one or 225 more segments as follows: 227 Send Loop: 229 a) If available unsent data exists and the receiver's advertised 230 window allows, transmit one segment of up to SMSS octets of 231 previously unsent data starting with sequence number 232 HighData+1 and update HighData to reflect the transmission of 233 the data segment. Otherwise, exit Send Loop. 235 b) Run SetPipe() to re-calculate the number of outstanding 236 octets in the network. If cwnd - pipe >= 1 SMSS, go to step 237 a) of Send Loop. Otherwise, exit Send Loop. 239 5B) Invoke Fast Retransmit and enter loss recovery: 241 Initiate a loss recovery phase, per the fast retransmit 242 algorithm outlined in [RFC2581] and continue with a fast 243 recovery algorithm, such as the SACK-based loss recovery 244 algorithm outlined in [RFC3517]. 246 3. Discussion 248 In scenarios where no ACK losses nor reordering occur and the first 249 acknowledgement with SACK information is not the ACK held due to 250 delayed acknowledgements mechanism, the new SACK information with 251 each duplicate ACK covers a single segment. In such a case, this 252 algorithm will trigger loss recovery after three duplicate 253 acknowledgements and will allow transmission of a single new segment 254 using Limited Transmit on each acknowledgement. This is identical 255 to the behavior that would occur without this algorithm (assuming 256 DupThresh is 3 and that all segments are SMSS sized). This scenario 257 together with other scenarios describing the behavior of the 258 algorithm are depicted in Appendix A. 260 A set of potential issues to consider with the algorithm are 261 discussed in the following. 263 3.1. Small Segment Sender 265 If a TCP sender is sending small segments (usually intentionally 266 overriding Nagle algorithm [RFC896]), the IsLost(SND.UNA) used in 267 step 4 of the algorithm might fail to detect the need for loss 268 recovery on the third duplicate acknowledgement because not enough 269 octets have been SACKed to cover DupThresh * SMSS bytes above 270 SND.UNA. If the SACKed octets are discontiguous (the second rule of 271 IsLost()), the loss recovery is still triggered on time. Otherwise, 272 the traditional duplicate ACKs algorithm needs to be used as a 273 fallback. Step 3 and the latter condition of step 4 implement the 274 traditional algorithm paraller to the SACK block based detection, 275 however, it comes with a cost of lost robustness against ACK losses 276 as expected. 278 Alternatively, a TCP sender that is able to discern segment 279 boundaries accurately can consider full segments in IsLost() 280 regardless of segment size. Therefore, such a TCP sender can avoid 281 the problem with small segments using IsLost(SND.UNA) check alone 282 which means that step 3 and the latter condition of step 4 are 283 redundant and do not have to be implemented. 285 Note: the small segments problem is not unique to this algorithm but 286 also the SACK-based loss recovery [RFC3517] encounters it because of 287 how IsLost() is defined. 289 3.2. One Segment is Small 291 A variant of small segment sender case is the case where only one of 292 the SACKed segments is smaller than SMSS (possible even with Nagle 293 enabled). If TCP sender lacks ability to use the improved method by 294 discerning segment boundaries but still wants robustness against ACK 295 losses in this case, it MAY replace IsLost(SND.UNA) with test: 297 SACKed octets > SMSS * (DupThresh - 1) 299 3.3. SACK Capability Misbehavior 301 If the receiver represents such a SACK misbehavior that it 302 advertizes SACK capability but never sends any SACK blocks when it 303 should, this algorithm fails to enter loss recovery and 304 retransmission timeout is required for recovery. However, such 305 misbehavior does not allow SACK-based loss recovery [RFC3517] to 306 work either, and a TCP sender will anyway require a timeout to 307 recover. 309 3.4. Compatibility with Duplicate ACK based Loss Recovery Algorithms 311 This algorithm SHOULD NOT be used together with a fast recovery 312 algorithm that determines the segments that have left the network 313 based on the number of arriving duplicate acknowledgements (e.g., 314 NewReno [RFC3782]), instead of the actual segments reported by SACK. 316 In presence of ACK reordering such an algorithm will count the 317 delayed duplicate acknowledgements during the fast recovery 318 algorithm as extra while detemining the number of packets that have 319 left the network. 321 In general there should be very little reason to combine this 322 algorithm with a loss recovery algorithm that is based on inferior, 323 non-SACK based information only. 325 4. Security Considerations 327 A malicious TCP receiver may send false SACK information for 328 sequence number ranges which it has not received in order to trigger 329 Fast Retransmit sooner. Such behavior would only be useful when out- 330 of-order segments have arrived because otherwise the flow undergoes 331 a loss recovery with a window reduction. This kind of lying involves 332 guessing which segments will arrive later. In case the guess was 333 wrong, the performance of the flow is ruined because the TCP sender 334 will need a retransmission timeout as it will not retransmit the 335 segments until it assumes SACK reneging. On a successful guess the 336 attacker is able to trigger the recovery slightly earlier. The later 337 segments would have allowed reporting the very same regions with 338 SACK anyway. Therefore, the gain from this attack is small, hardly 339 justifiable considering the drastic effect of a misguess. Also, a 340 similar attack can be made with the duplicate acknowledgment based 341 algorithm (even if the new SACK information rule is applied) by 342 sending false duplicate acknowledgements with false SACK ranges, and 343 trivially without the new SACK information rule. 345 A variation of the lying attack discards reliability of the flow but 346 as soon as the reliability is not a concern of the receiver, a 347 number of simpler ways exist to attack TCP independently of this 348 algorithm. Thus this algorithm is not considered to weaken TCP 349 security properties against false information. 351 PLACEHOLDER: SACK splitting to make recovery to start sooner than it 352 should or to trigger more segments (with less bandwidth in the 353 opposite direction than using multiple duplicate ACKs). 355 5. IANA Considerations 357 This document has no actions for IANA. 359 6. Acknowledgements 361 Appendix 363 A. Scenarios 365 A.1. Basic Case 367 In this scenario no Delayed ACK, ACK losses, reordering or other 368 "abnormal" behavior happens. For simplicity all the segments are 369 SMSS sized. 371 Once the TCP receiver gets first out-of-order segment, it sends a 372 duplicate ACK with SACK information about the received octets. The 373 following two out-of-order segments trigger a duplicate ACK each, 374 with the corresponding range SACKed in addition to the previously 375 know information. The sender gets those duplicate ACKs in-order, 376 each of them will SACK a new previously unknown segment. 378 This algorithm triggers loss recovery on third duplicate ACK because 379 IsLost returns true as DupThresh * SMSS bytes became SACKed above 380 the SND.UNA on the same acknowledgement, thus the behavior is 381 identical to that of a sender which is using duplicate 382 acknowledgments. If Limited Transmit is in use, two first duplicate 383 ACKs allow a single segment to be sent with either of the algorithms 384 (Pipe is decremented by SMSS by the SACKed octets per ACK allowing 385 SMSS worth of new octets). 387 ACK Transmitted Received ACK Sent 388 Received Segment Segment (Including SACK Blocks) 390 1000 391 3000-3499 3000-3499 (delayed ACK) 392 3500-3999 3500-3999 4000 393 2000 394 4000-4499 (dropped) 395 4500-4999 4500-4999 4000, SACK=4500-5000 396 3000 397 5000-5499 5000-5499 4000, SACK=4500-5500 398 5500-5999 5500-5999 4000, SACK=4500-6000 399 4000 400 6000-6499 6000-6499 4000, SACK=4500-6500 401 6500-6999 6500-6999 4000, SACK=4500-7000 402 4000, SACK=4500-5000 403 7000-7499 7000-7499 4000, SACK=4500-7500 405 4000, SACK=4500-5500 406 7500-7999 7500-7999 4000, SACK=4500-8000 407 4000, SACK=4500-6000 408 4000-4499 4000-4499 8000 409 4000, SACK=4500-6500 411 A.2. Delayed ACK 413 A basic case with delayed ACK send the first ACK with SACK 414 information but since the previous ACK was sent with a lower 415 sequence number because an acknowledgment is held by delayed ACK, 416 the sender will not considered it as duplicate ACK. Because the 417 segment contains SACK information that is identical to the basic 418 case, the sender can use Limited Transmit with the same segments as 419 in the basic case and will start loss recovery at the third 420 acknowledgment, i.e., with the second duplicate acknowledgment. In 421 the same situation the duplicate ACK based sender will have to wait 422 for one more duplicate ACK to arrive to do the same as the first 423 acknowledgment is fully "wasted". 425 Technically an acknowledgement with a sequence number higher than 426 what was previously acknowledged is not a duplicate acknowledgement 427 but a presence of the SACK block tells another story revealing the 428 receiver which used delayed ACK, and thus the missing duplicate 429 acknowledgement in between. The response of a TCP sender taking 430 advantage of such inferred duplicate acknowledgements is well within 431 the guidelines of packet conservation principle [Jac88] as it still 432 sends only when segments have left the network. 434 ACK Transmitted Received ACK Sent 435 Received Segment Segment (Including SACK Blocks) 437 1500 438 3000-3499 3000-3499 3500 439 3500-3999 3500-3999 (delayed ACK) 440 2500 441 4000-4499 (dropped) 442 4500-4999 4500-4999 4000, SACK=4500-5000 443 3500 444 5000-5499 5000-5499 4000, SACK=4500-5500 445 5500-5999 5500-5999 4000, SACK=4500-6000 446 4000, SACK=4500-5000 447 6000-6499 6000-6499 4000, SACK=4500-6500 448 6500-6999 6500-6999 4000, SACK=4500-7000 449 4000, SACK=4500-5500 450 7000-7499 7000-7499 4000, SACK=4500-7500 451 4000, SACK=4500-6000 452 4000-4499 4000-4499 7500 453 4000, SACK=4500-6500 455 A.3. ACK Losses 457 This case with ACK loss shares much behavior with the case with 458 delayed ACK. If hole at rcv.nxt is filled, the sender will notice 459 that cumulative ACK advanced. In case of out-of-order segments the 460 first ACK which gets through to the sender includes SACK blocks up 461 to the quantity the SACK block redundancy is able to cover. With 462 this algorithm the sender immediately takes use of all the 463 information that is made available by the incoming ACK. 465 ACK Transmitted Received ACK Sent 466 Received Segment Segment (Including SACK Blocks) 468 1000 469 3000-3499 3000-3499 (delayed ACK) 470 3500-3999 3500-3999 4000 471 2000 472 4000-4499 (dropped) 473 4500-4999 4500-4999 4000, SACK=4500-5000 474 (dropped) 475 3000 476 5000-5499 5000-5499 4000, SACK=4500-5500 477 5500-5999 5500-5999 4000, SACK=4500-6000 478 4000 479 6000-6499 6000-6499 4000, SACK=4500-6500 480 6500-6999 6500-6999 4000, SACK=4500-7000 481 4000, SACK=4500-5500 (two segments left the network) 482 7000-7499 7000-7499 4000, SACK=4500-7500 483 7500-7999 7500-7999 4000, SACK=4500-8000 484 4000, SACK=4500-6000 485 4000-4499 4000-4499 8000 486 4000, SACK=4500-6500 488 A.4. ACK Reordering 490 With ACK reordering an ACK is postponed. Due to redundancy the next 491 ACK after postponed one contains not only its own information but 492 also the information of the reordered ACK (similar to the ACK losses 493 case). Then when the reordered ACK arrives, the sender already knows 494 about the information it provides and therefore no actions are taken 495 with this algorithm. 497 ACK Transmitted Received ACK Sent 498 Received Segment Segment (Including SACK Blocks) 500 1000 501 3000-3499 3000-3499 (delayed ACK) 502 3500-3999 3500-3999 4000 503 2000 504 4000-4499 (dropped) 505 4500-4999 4500-4999 4000, SACK=4500-5000 506 (delayed) 507 3000 508 5000-5499 5000-5499 4000, SACK=4500-5500 509 5500-5999 5500-5999 4000, SACK=4500-6000 510 4000 511 6000-6499 6000-6499 4000, SACK=4500-6500 512 6500-6999 6500-6999 4000, SACK=4500-7000 513 4000, SACK=4500-5500 514 7000-7499 7000-7499 4000, SACK=4500-7500 515 7500-7999 7500-7999 4000, SACK=4500-8000 516 4000, SACK=4500-6000 517 4000-4499 4000-4499 8000 518 4000, SACK=4500-5000 (has only redundant information) 519 4000, SACK=4500-6500 521 A.5. Packet Duplication 523 Packet duplication happens either due to unnecessary retransmission 524 or hardware duplication. It adds a redundant ACK which has only 525 redundant information or a data segment to the stream which will 526 triggers a redundant duplicate ACK (possibly with SACK and/or DSACK 527 [RFC2883] information). Because neither adds any new SACKed octets 528 at the sender, this algorithm will not do anything while duplicate 529 ACK based receiver would falsely consider it as a duplicate ACK. 531 If one of the redundant ACKs is lost, the effect of duplication is 532 just negated. 534 It is possible for the sender to detect this case using DSACK alone. 536 A.6. Mitigation of Blind Throughput Reduction Attack 538 In case an attacker knows or is able to guess 4-tuple of a TCP 539 connection, it may apply a blind throughput reduction attack. In 540 this attack TCP is tricked to send duplicate ACK to the other 541 endpoint using out-of-window segments which it is considerably 542 easier to achieve than a match with sequence numbers. If more than 543 dupThresh duplicate ACKs can be triggered in row without any 544 legimate segment that advances acknowledged sequence number, the 545 other end acts according that false congestion signal and halves the 546 window. 548 With this algorithm such duplicate ACKs are filtered because they do 549 not have any new in-window SACK blocks (DSACK [RFC2883] might be 550 present though). 552 References 554 Normative References 556 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 557 793, September 1981. 559 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, 560 "TCP Selective Acknowledgment Options", RFC 2018, 561 October 1996. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 567 Control", RFC 2581, April 1999. 569 [RFC2581bis] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 570 Control", RFC 2581bis, May 2009. 572 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 573 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 574 January 2001. 576 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, 577 "A Conservative Selective Acknowledgment (SACK)-based 578 Loss Recovery Algorithm for TCP", RFC 3517, April 2003. 580 Informative References 582 [FARI08] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 583 Acknowledgement Congestion Control to TCP", 584 Internet-Draft, draft-floyd-tcpm-ackcc-06, July 2009. 586 [Jac88] Jacobson, V., "Congestion Avoidance and Control", In 587 Proc. ACM SIGCOMM 88. 589 [MM96] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining 590 TCP Congestion Control," Proceedings of SIGCOMM'96, August 591 1996, Stanford, CA. 593 [RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 594 RFC 896, January 1984. 596 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 597 Extension to the Selective Acknowledgement (SACK) Option 598 for TCP", RFC 2883, July 2000. 600 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 601 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 602 April 2004. 604 AUTHORS' ADDRESSES 606 Ilpo Jarvinen 607 University of Helsinki 608 P.O. Box 68 609 FI-00014 UNIVERSITY OF HELSINKI 610 Finland 611 Email: ilpo.jarvinen@helsinki.fi 613 Markku Kojo 614 University of Helsinki 615 P.O. Box 68 616 FI-00014 UNIVERSITY OF HELSINKI 617 Finland 618 Email: kojo@cs.helsinki.fi