idnits 2.17.1 draft-blanton-tcpm-3517bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2011) is 4762 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) == Missing Reference: 'RFC2581' is mentioned on line 86, but not defined ** Obsolete undefined reference: RFC 2581 (Obsoleted by RFC 5681) == Missing Reference: 'A' is mentioned on line 143, but not defined == Missing Reference: 'B' is mentioned on line 143, but not defined == Unused Reference: 'RFC2026' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'Jac90' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC3042' is defined on line 599, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Duplicate reference: RFC2018, mentioned in 'Errata1610', was also mentioned in 'RFC2018'. -- Obsolete informational reference (is this intentional?): RFC 2582 (Obsoleted by RFC 3782) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force E. Blanton 2 INTERNET-DRAFT Purdue University 3 draft-blanton-tcpm-3517bis-01.txt M. Allman 4 ICSI 5 L. Wang 6 Juniper Networks 7 I. Jarvinen 8 M. Kojo 9 University of Helsinki 10 April 13, 2011 12 A Conservative Selective Acknowledgment (SACK)-based 13 Loss Recovery Algorithm for TCP 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 13, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document presents a conservative loss recovery algorithm for TCP 56 that is based on the use of the selective acknowledgment (SACK) TCP 57 option. The algorithm presented in this document conforms to the 58 spirit of the current congestion control specification (RFC 2581), 59 but allows TCP senders to recover more effectively when multiple 60 segments are lost from a single flight of data. 62 1 Introduction 64 This document presents a conservative loss recovery algorithm for TCP 65 that is based on the use of the selective acknowledgment (SACK) TCP 66 option. While the TCP SACK [RFC2018] is being steadily deployed in 67 the Internet [All00], there is evidence that hosts are not using the 68 SACK information when making retransmission and congestion control 69 decisions [PF01]. The goal of this document is to outline one 70 straightforward method for TCP implementations to use SACK 71 information to increase performance. 73 [RFC2581] allows advanced loss recovery algorithms to be used by TCP 74 [RFC793] provided that they follow the spirit of TCP's congestion 75 control algorithms [RFC2581, RFC2914]. [RFC2582] outlines one such 76 advanced recovery algorithm called NewReno. This document outlines a 77 loss recovery algorithm that uses the SACK [RFC2018] TCP option to 78 enhance TCP's loss recovery. The algorithm outlined in this 79 document, heavily based on the algorithm detailed in [FF96], is a 80 conservative replacement of the fast recovery algorithm [Jac90, 81 RFC2581]. The algorithm specified in this document is a 82 straightforward SACK-based loss recovery strategy that follows the 83 guidelines set in [RFC2581] and can safely be used in TCP 84 implementations. Alternate SACK-based loss recovery methods can be 85 used in TCP as implementers see fit (as long as the alternate 86 algorithms follow the guidelines provided in [RFC2581]). Please 87 note, however, that the SACK-based decisions in this document (such 88 as what segments are to be sent at what time) are largely decoupled 89 from the congestion control algorithms, and as such can be treated as 90 separate issues if so desired. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in BCP 14, RFC 2119 95 [RFC2119]. 97 2 Definitions 99 The reader is expected to be familiar with the definitions given in 100 [RFC5681]. 102 The reader is assumed to be familiar with selective acknowledgments 103 as specified in [RFC2018]. 105 For the purposes of explaining the SACK-based loss recovery algorithm 106 we define five variables that a TCP sender stores: 108 "HighACK" is the sequence number of the highest byte of data that 109 has been cumulatively ACKed at a given point. 111 "HighData" is the highest sequence number transmitted at a given 112 point. 114 "HighRxt" is the highest sequence number which has been 115 retransmitted during the current loss recovery phase. 117 "Pipe" is a sender's estimate of the number of bytes outstanding 118 in the network. This is used during recovery for limiting the 119 sender's sending rate. The pipe variable allows TCP to use a 120 fundamentally different congestion control than specified in 121 [RFC5681]. The algorithm is often referred to as the "pipe 122 algorithm". 124 "DupAcks" is the number of duplicate acknowledgments received 125 since the last cumulative acknowledgment. 127 For the purposes of this specification we define a "duplicate 128 acknowledgment" as a segment that arrives carrying a SACK block which 129 identifies previously unacknowledged and un-SACKed octets between 130 SND.UNA and SND.NXT as received. Note that an ACK which carries new 131 SACK data is counted as a duplicate acknowledgment under this 132 definition even if it carries new data or changes the advertised 133 window, which is different from the definition of duplicate 134 acknowledgment in [RFC5681]. 136 We define a variable "DupThresh" that holds the number of duplicate 137 acknowledgments required to trigger a retransmission. Per [RFC5681] 138 this threshold is defined to be 3 duplicate acknowledgments. 139 However, implementers should consult any updates to [RFC5681] to 140 determine the current value for DupThresh (or method for determining 141 its value). 143 Finally, a range of sequence numbers [A,B] is said to "cover" 144 sequence number S if A <= S <= B. 146 3 Keeping Track of SACK Information 148 For a TCP sender to implement the algorithm defined in the next 149 section it must keep a data structure to store incoming selective 150 acknowledgment information on a per connection basis. Such a data 151 structure is commonly called the "scoreboard". The specifics of the 152 scoreboard data structure are out of scope for this document (as long 153 as the implementation can perform all functions required by this 154 specification). 156 Note that this document refers to keeping account of (marking) 157 individual octets of data transferred across a TCP connection. A 158 real-world implementation of the scoreboard would likely prefer to 159 manage this data as sequence number ranges. The algorithms presented 160 here allow this, but require arbitrary sequence number ranges to be 161 marked as having been selectively acknowledged. 163 Finally, note that the algorithm in this document assumes a 164 sender that is not keeping track of segment boundaries after 165 transmitting a segment. It is possible that a sender that did 166 keep this extra state may be able to use a more refined and 167 precise algorithm than the one presented herein, however, we 168 leave this as future work. 170 4 Processing and Acting Upon SACK Information 172 For the purposes of the algorithm defined in this document the 173 scoreboard SHOULD implement the following functions: 175 Update (): 177 Given the information provided in an ACK, each octet that is 178 cumulatively ACKed or SACKed should be marked accordingly in the 179 scoreboard data structure, and the total number of octets SACKed 180 should be recorded. 182 Note: SACK information is advisory and therefore SACKed data MUST 183 NOT be removed from TCP's retransmission buffer until the data is 184 cumulatively acknowledged [RFC2018]. 186 IsLost (SeqNum): 188 This routine returns whether the given sequence number is 189 considered to be lost. The routine returns true when either 190 DupThresh discontiguous SACKed sequences have arrived above 191 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence 192 numbers greater than 'SeqNum' have been SACKed. Otherwise, the 193 routine returns false. 195 SetPipe (): 197 This routine traverses the sequence space from HighACK to HighData 198 and MUST set the "pipe" variable to an estimate of the number of 199 octets that are currently in transit between the TCP sender and 200 the TCP receiver. After initializing pipe to zero the following 201 steps are taken for each octet 'S1' in the sequence space between 202 HighACK and HighData that has not been SACKed: 204 (a) If IsLost (S1) returns false: 206 Pipe is incremented by 1 octet. 208 The effect of this condition is that pipe is incremented for 209 packets that have not been SACKed and have not been determined 210 to have been lost (i.e., those segments that are still assumed 211 to be in the network). 213 (b) If S1 <= HighRxt: 215 Pipe is incremented by 1 octet. 217 The effect of this condition is that pipe is incremented for 218 the retransmission of the octet. 220 Note that octets retransmitted without being considered lost are 221 counted twice by the above mechanism. 223 NextSeg (): 225 This routine uses the scoreboard data structure maintained by the 226 Update() function to determine what to transmit based on the SACK 227 information that has arrived from the data receiver (and hence 228 been marked in the scoreboard). NextSeg () MUST return the 229 sequence number range of the next segment that is to be 230 transmitted, per the following rules: 232 (1) If there exists a smallest unSACKed sequence number 'S2' that 233 meets the following three criteria for determining loss, the 234 sequence range of one segment of up to SMSS octets starting 235 with S2 MUST be returned. 237 (1.a) S2 is greater than HighRxt. 239 (1.b) S2 is less than the highest octet covered by any 240 received SACK. 242 (1.c) IsLost (S2) returns true. 244 (2) If no sequence number 'S2' per rule (1) exists but there 245 exists available unsent data and the receiver's advertised 246 window allows, the sequence range of one segment of up to SMSS 247 octets of previously unsent data starting with sequence number 248 HighData+1 MUST be returned. 250 (3) If the conditions for rules (1) and (2) fail, but there exists 251 an unSACKed sequence number 'S3' that meets the criteria for 252 detecting loss given in steps (1.a) and (1.b) above 253 (specifically excluding step (1.c)) then one segment of up to 254 SMSS octets starting with S3 MAY be returned. 256 Note that rule (3) is a sort of retransmission "last resort". 257 It allows for retransmission of sequence numbers even when the 258 sender has less certainty a segment has been lost than as with 259 rule (1). Retransmitting segments via rule (3) will help 260 sustain TCP's ACK clock and therefore can potentially help 261 avoid retransmission timeouts. However, in sending these 262 segments the sender has two copies of the same data considered 263 to be in the network (and also in the Pipe estimate). When an 264 ACK or SACK arrives covering this retransmitted segment, the 265 sender cannot be sure exactly how much data left the network 266 (one of the two transmissions of the packet or both 267 transmissions of the packet). Therefore the sender may 268 underestimate Pipe by considering both segments to have left 269 the network when it is possible that only one of the two has. 271 We believe that the triggering of rule (3) will be rare and 272 that the implications are likely limited to corner cases 273 relative to the entire recovery algorithm. Therefore we leave 274 the decision of whether or not to use rule (3) to 275 implementors. 277 (4) If the conditions for each of (1), (2), and (3) are not met, 278 then NextSeg () MUST indicate failure, and no segment is 279 returned. 281 Note: The SACK-based loss recovery algorithm outlined in this 282 document requires more computational resources than previous TCP loss 283 recovery strategies. However, we believe the scoreboard data 284 structure can be implemented in a reasonably efficient manner (both 285 in terms of computation complexity and memory usage) in most TCP 286 implementations. 288 5 Algorithm Details 290 Upon the receipt of any ACK containing SACK information, the 291 scoreboard MUST be updated via the Update () routine. 293 If the incoming ACK is a cumulative acknowledgment, the TCP MUST 294 reset DupAcks to zero. 296 If the incoming ACK is a duplicate acknowledgment and the TCP is 297 not currently in loss recovery, the TCP MUST increase DupAcks by 298 one and take the following steps: 300 (1) If DupAcks >= DupThresh, go to step (4). 302 (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns 303 true---indicating at least three segments have arrived above 304 the current cumulative acknowledgment point, which is taken 305 to indicate loss---go to step (4). 307 (3) The TCP MAY transmit previously unsent data segments as per 308 Limited Transmit [RFC5681], except that the number of octets 309 which may be sent is governed by Pipe and cwnd as follows: 311 (3.1) Set HighRxt to SND.UNA. 313 (3.2) Run SetPipe (). 315 (3.3) If (cwnd - pipe) >= 1 SMSS, there exists previously 316 unsent data, and the receiver's advertised window 317 allows, transmit up to 1 SMSS of data starting with the 318 octet HighData+1 and update HighData to reflect this 319 transmission, then return to (3.2). 321 (3.4) Terminate processing of this ACK. 323 (4) Invoke Fast Retransmit and enter loss recovery as follows: 325 (4.1) RecoveryPoint = HighData 327 When the TCP sender receives a cumulative ACK for this 328 data octet the loss recovery phase is terminated. 330 (4.2) ssthresh = cwnd = (FlightSize / 2) 332 The congestion window (cwnd) and slow start threshold 333 (ssthresh) are reduced to half of FlightSize per 334 [RFC5681]. 336 (4.3) Retransmit the first data segment presumed dropped -- the segment 337 starting with sequence number HighACK + 1. To prevent 338 repeated retransmission of the same data, set HighRxt 339 to the highest sequence number in the retransmitted 340 segment. 342 (4.4) Run SetPipe () 344 Set a "pipe" variable to the number of outstanding 345 octets currently "in the pipe"; this is the data which 346 has been sent by the TCP sender but for which no 347 cumulative or selective acknowledgment has been 348 received and the data has not been determined to have 349 been dropped in the network. It is assumed that the 350 data is still traversing the network path. 352 (4.5) In order to take advantage of potential additional 353 available cwnd, proceed to step (C) below. 355 Once a TCP is in the loss recovery phase the following procedure MUST 356 be used for each arriving ACK: 358 (A) An incoming cumulative ACK for a sequence number greater than 359 RecoveryPoint signals the end of loss recovery and the loss 360 recovery phase MUST be terminated. Any information contained in 361 the scoreboard for sequence numbers greater than the new value of 362 HighACK SHOULD NOT be cleared when leaving the loss recovery 363 phase. 365 (B) Upon receipt of an ACK that does not cover RecoveryPoint the 366 following actions MUST be taken: 368 (B.1) Use Update () to record the new SACK information conveyed 369 by the incoming ACK. 371 (B.2) Use SetPipe () to re-calculate the number of octets still 372 in the network. 374 (C) If cwnd - pipe >= 1 SMSS the sender SHOULD transmit one or more 375 segments as follows: 377 (C.1) The scoreboard MUST be queried via NextSeg () for the 378 sequence number range of the next segment to transmit (if any), 379 and the given segment sent. If NextSeg () returns failure (no 380 data to send) return without sending anything (i.e., terminate 381 steps C.1 -- C.5). 383 (C.2) If any of the data octets sent in (C.1) are below HighData, 384 HighRxt MUST be set to the highest sequence number of the 385 retransmitted segment. 387 (C.3) If any of the data octets sent in (C.1) are above HighData, 388 HighData must be updated to reflect the transmission of 389 previously unsent data. 391 (C.4) The estimate of the amount of data outstanding in the 392 network must be updated by incrementing pipe by the number of 393 octets transmitted in (C.1). 395 (C.5) If cwnd - pipe >= 1 SMSS, return to (C.1) 397 5.1 Retransmission Timeouts 399 In order to avoid memory deadlocks, the TCP receiver is allowed to 400 discard data that has already been selectively acknowledged. As a 401 result, [RFC2018] suggests that a TCP sender SHOULD expunge the SACK 402 information gathered from a receiver upon a retransmission timeout 403 "since the timeout might indicate that the data receiver has 404 reneged." Additionally, a TCP sender MUST "ignore prior SACK 405 information in determining which data to retransmit." However, since 406 the publication of [RFC2018] this has come to be viewed by some as 407 too strong. It has been suggested that, as long as robust tests for 408 reneging are present, an implementation can retain and use SACK 409 information across a timeout event [Errata1610]. While this document 410 does not change the specification in [RFC2018], we note that 411 implementers should consult any updates to [RFC2018] on this subject. 412 Further, a SACK TCP sender SHOULD utilize all SACK information made 413 available during the slow start phase of loss recovery following an 414 RTO. 416 If an RTO occurs during loss recovery as specified in this document, 417 RecoveryPoint MUST be set to HighData. Further, the new value of 418 RecoveryPoint MUST be preserved and the loss recovery algorithm 419 outlined in this document MUST be terminated. In addition, a new 420 recovery phase (as described in section 5) MUST NOT be initiated 421 until HighACK is greater than or equal to the new value of 422 RecoveryPoint. 424 As described in Sections 4 and 5, Update () SHOULD continue to be 425 used appropriately upon receipt of ACKs. This will allow the slow 426 start recovery period to benefit from all available information 427 provided by the receiver, despite the fact that SACK information was 428 expunged due to the RTO. 430 If there are segments missing from the receiver's buffer following 431 processing of the retransmitted segment, the corresponding ACK will 432 contain SACK information. In this case, a TCP sender SHOULD use this 433 SACK information when determining what data should be sent in each 434 segment of the slow start. The exact algorithm for this selection is 435 not specified in this document (specifically NextSeg () is 436 inappropriate during slow start after an RTO). A relatively 437 straightforward approach to "filling in" the sequence space reported 438 as missing should be a reasonable approach. 440 6 Managing the RTO Timer 442 The standard TCP RTO estimator is defined in [RFC2988]. Due to the 443 fact that the SACK algorithm in this document can have an impact on 444 the behavior of the estimator, implementers may wish to consider how 445 the timer is managed. [RFC2988] calls for the RTO timer to be 446 re-armed each time an ACK arrives that advances the cumulative ACK 447 point. Because the algorithm presented in this document can keep the 448 ACK clock going through a fairly significant loss event, 449 (comparatively longer than the algorithm described in [RFC5681]), on 450 some networks the loss event could last longer than the RTO. In this 451 case the RTO timer would expire prematurely and a segment that need 452 not be retransmitted would be resent. 454 Therefore we give implementers the latitude to use the standard 455 [RFC2988] style RTO management or, optionally, a more careful variant 456 that re-arms the RTO timer on each retransmission that is sent during 457 recovery MAY be used. This provides a more conservative timer than 458 specified in [RFC2988], and so may not always be an attractive 459 alternative. However, in some cases it may prevent needless 460 retransmissions, go-back-N transmission and further reduction of the 461 congestion window. 463 7 Research 465 The algorithm specified in this document is analyzed in [FF96], which 466 shows that the above algorithm is effective in reducing transfer time 467 over standard TCP Reno [RFC5681] when multiple segments are dropped 468 from a window of data (especially as the number of drops increases). 469 [AHKO97] shows that the algorithm defined in this document can 470 greatly improve throughput in connections traversing satellite 471 channels. 473 8 Security Considerations 475 The algorithm presented in this paper shares security considerations 476 with [RFC5681]. A key difference is that an algorithm based on SACKs 477 is more robust against attackers forging duplicate ACKs to force the 478 TCP sender to reduce cwnd. With SACKs, TCP senders have an 479 additional check on whether or not a particular ACK is legitimate. 480 While not fool-proof, SACK does provide some amount of protection in 481 this area. 483 Similarly, [CPNI309] sketches a variant of a blind attack [RFC5961] 484 whereby an attacker can spoof out-of-window data to a TCP endpoint, 485 causing it to respond to the legitimate peer with a duplicate 486 cumulative ACK, per [RFC793]. Adding a SACK-based requirement to 487 trigger loss recovery effectively mitigates this attack, as the 488 duplicate ACKs caused by out-of-window segments will not contain SACK 489 information indicating reception of previously un-SACKED in-window 490 data. 492 9 Changes Relative to RFC 3517 494 The state variable "DupAcks" has been added to the list of variables 495 maintained by this algorithm, and its usage specified. 497 The function IsLost () has been modified to require that more than 498 (DupThresh - 1) * SMSS octets have been SACKed above a given sequence 499 number as indication that it is lost, changed from at least 500 (DupThresh * SMSS). This retains the requirement that at least three 501 segments following the sequence number in question have been SACKed, 502 while improving detection in the event that the sender has 503 outstanding segments which are smaller than SMSS. 505 The definition of a "duplicate acknowledgment" has been modified to 506 utilize the SACK information in detecting loss. Duplicate cumulative 507 acknowledgments can be caused by either loss or reordering in the 508 network. To disambiguate loss and reordering TCP's fast retransmit 509 algorithm [RFC5681] waits until three duplicate ACKs arrive to 510 trigger loss recovery. This notion was then the basis for the 511 algorithm specified in [RFC3517]. However, with SACK information 512 there is no need to rely blindly on the cumulative acknowledgment 513 field. We can leverage the additional information present in the 514 SACK blocks to understand that three segments have arrived at the 515 receiver which lie above a gap in the sequence space, and can use 516 that to trigger loss recovery. This notion was used in [RFC3517] 517 during loss recovery, and the change in this document is that the 518 notion is also used to enter a loss recovery phase. 520 Acknowledgments 522 The authors wish to thank Sally Floyd for encouraging [RFC3517] 523 and commenting on early drafts. The algorithm described in this 524 document is loosely based on an algorithm outlined by Kevin Fall 525 and Sally Floyd in [FF96], although the authors of this document 526 assume responsibility for any mistakes in the above text. 528 [RFC3517] was co-authored by Kevin Fall, who provided crucial input 529 to that document and hence this follow-on work. 531 Murali Bashyam, Ken Calvert, Tom Henderson, Reiner Ludwig, 532 Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson and 533 Venkat Venkatsubra provided valuable feedback on earlier versions 534 of this document. 536 We thank Matt Mathis and Jamshid Mahdavi for implementing the 537 scoreboard in ns and hence guiding our thinking in keeping track 538 of SACK state. 540 The first author would like to thank Ohio University and the Ohio 541 University Internetworking Research Group for supporting the bulk of 542 his work on this project. 544 Normative References 546 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 547 793, September 1981. 549 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 550 Selective Acknowledgment Options", RFC 2018, October 1996. 552 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 553 3", BCP 9, RFC 2026, October 1996. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion 559 Control", RFC 5681, September 2009. 561 Informative References 563 [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann, "TCP 564 Performance Over Satellite Links", Proceedings of the Fifth 565 International Conference on Telecommunications Systems, 566 Nashville, TN, March, 1997. 568 [All00] Mark Allman, "A Web Server's View of the Transport Layer", 569 ACM Computer Communication Review, 30(5), October 2000. 571 [CPNI309] Fernando Gont, "Security Assessment of the Transmission 572 Control Protocol (TCP)", CPNI Technical Note 3/2009, 573 http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf, 574 February 2009. 576 [Errata1610] Matt Mathis, "RFC Errata Report 1610 for RFC 2018", 577 http://www.rfc-editor.org/errata_search.php?eid=1610, 578 Verified 2008-12-09. 580 [FF96] Kevin Fall and Sally Floyd, "Simulation-based Comparisons 581 of Tahoe, Reno and SACK TCP", Computer Communication 582 Review, July 1996. 584 [Jac90] Van Jacobson, "Modified TCP Congestion Avoidance Algorithm", 585 Technical Report, LBL, April 1990. 587 [PF01] Jitendra Padhye, Sally Floyd "Identifying the TCP Behavior 588 of Web Servers", ACM SIGCOMM, August 2001. 590 [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to 591 TCP's Fast Recovery Algorithm", RFC 2582, April 1999. 593 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 594 2914, September 2000. 596 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 597 Timer", RFC 2988, November 2000. 599 [RFC3042] Allman, M., Balakrishnan, H, and S. Floyd, "Enhancing TCP's 600 Loss Recovery Using Limited Transmit", RFC 3042, January 601 2001. 603 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 604 Conservative Selective Acknowledgment (SACK)-based Loss 605 Recovery Algorithm for TCP", RFC 3517, April 2003. 607 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 608 Robustness to Blind In-Window Attacks", RFC 5961, August 609 2010. 611 Authors' Addresses 613 Ethan Blanton 614 Purdue University Computer Sciences 615 1398 Computer Science Building 616 West Lafayette, IN 47907 618 EMail: eblanton@cs.purdue.edu 620 Mark Allman 621 International Computer Science Institute 622 1947 Center St. Suite 600 623 Berkeley, CA 94704 625 Phone: 440-235-1792 626 EMail: mallman@icir.org 627 http://www.icir.org/mallman 629 Lili Wang 630 Juniper Networks 631 10 Technology Park Drive 632 Westford, MA 01886 634 EMail: liliw@juniper.net 636 Ilpo Jarvinen 637 University of Helsinki 638 P.O. Box 68 639 FI-00014 UNIVERSITY OF HELSINKI 640 Finland 642 Email: ilpo.jarvinen@helsinki.fi 643 Markku Kojo 644 University of Helsinki 645 P.O. Box 68 646 FI-00014 UNIVERSITY OF HELSINKI 647 Finland 649 Email: kojo@cs.helsinki.fi