idnits 2.17.1 draft-ietf-tcpm-tcp-dcr-03.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 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) 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 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.) -- The document date (February 2005) is 7010 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) ** 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 2988 (Obsoleted by RFC 6298) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sumitha Bhandarkar 2 INTERNET DRAFT A. L. Narasimha Reddy 3 draft-ietf-tcpm-tcp-dcr-03.txt Texas A&M University 4 Expires : August 2005 Mark Allman 5 ICIR 6 Ethan Blanton 7 Purdue University 8 February 2005 10 Improving the Robustness of TCP to Non-Congestion Events 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 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 Internet- 24 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 This Internet-Draft will expire in August 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract: 45 This document specifies Non-Congestion Robustness (NCR) for TCP. In 46 the absence of explicit congestion notification from the network, 47 TCP's loss recovery algorithms treat the receipt of three duplicate 48 acknowledgments as an implicit indication of congestion in the 49 network. This is not always correct, notably in the case when 50 network paths reorder segments (for whatever reason), resulting in 51 degraded performance. TCP-NCR is designed to mitigate this degraded 52 performance by increasing the number of duplicate acknowledgments 53 required to trigger loss recovery, based on the current state of the 54 connection, in an effort to disambiguate true segment loss from 55 segment reordering. In addition, we specify a change to TCP's 56 congestion reaction decision point, as well (but, do not require such 57 a change to use NCR). This document specifies the changes to TCP, as 58 well as the costs and benefits of these modifications. 60 Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 63 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 64 "OPTIONAL" in this document are to be interpreted as described 65 in [RFC2119]. 67 Readers should be familiar with the TCP terminology given in 68 [RFC2581] and [RFC3517]. 70 1. Introduction 72 One strength of TCP [RFC793] lies in its ability to adjust its 73 sending rate according to the perceived congestion in the network 74 [Jac88,RFC2581]. In the absence of explicit notification of 75 congestion from the network, TCP uses segment loss as an indication 76 of congestion (i.e., assuming queue overflow). TCP receivers send 77 cumulative acknowledgments (ACKs) indicating the next sequence number 78 expected from the sender for arriving segments [RFC793]. When 79 segments arrive out of order duplicate ACKs are generated. As 80 specified in [RFC2581], a TCP sender uses the arrival of three 81 duplicate ACKs as an indication of segment loss. The TCP sender 82 retransmits the lost segment and reduces the load imposed on the 83 network, assuming the segment loss was caused by resource contention 84 within the network path. The TCP sender does not assume loss on the 85 first duplicate ACK, but waits for three dupacks to account for mild 86 reordering. However, the use of this constant number of duplicate 87 ACKs has a number of implications that can be mitigated if the 88 duplicate ACK requirement is changed. 90 The following is an example of TCP's behavior: 92 + TCP A is the data sender and TCP B is the data receiver. 94 + TCP A sends 10 segments each consisting of a single data byte 95 (i.e., transmits bytes 1-10 in segments 1-10). 97 + Assume segment 3 is dropped in the network. 99 + TCP B cumulatively acknowledges segments 1 and 2, making the 100 cumulative ACK transmitted to the sender 3 (the next expected 101 sequence number). (Note: TCP B may generate one or two ACKs, 102 depending on whether delayed ACKs [RFC1122,RFC2581] are 103 employed.) 105 + The arrival of segments 4-10 at TCP B will each trigger the 106 transmission of a cumulative ACK for sequence number 3. (Note: 107 [RFC2581] recommends that delayed ACKs not be used when the ACK 108 is triggered by an out-of-order segment.) 110 + When TCP A receives the third duplicate ACK (or fourth ACK 111 overall) for sequence number 3, TCP A will retransmit 112 segment 3 and reduce the sending rate by roughly half (see 113 [RFC2581] for specifics on the congestion control state 114 adjustments). 116 Alternatively, suppose segment 3 was not dropped by the network, but 117 rather delayed such that segment 3 arrives after segment 10. The 118 above scenario will play out in precisely the same manner. In other 119 words, TCP is not capable of disambiguating that level of packet 120 reordering from loss. 122 The following is the specific motivation behind making TCP robust to 123 reordered segments: 125 * A number of Internet measurement studies have shown that packet 126 reordering is not a rare phenomenon [Pax97,BPS99,JIDKT03,GPL04]. 127 Further, the reordering can be well beyond that which fast 128 retransmit can cope with using the arrival of three duplicate 129 ACKs to disambiguate loss and reordering. 131 * [BA02,ZKFP03] show the negative performance implications that 132 packet reordering has on current TCP. 134 * The requirement imposed by TCP for almost in-order packet 135 delivery places a severe constraint on the design of future 136 technology. Novel routing algorithms, network components, 137 link-layer retransmission mechanisms and applications could all 138 be looked at with a fresh perspective if TCP were to be more 139 robust to segment reordering. For instance, high speed packet 140 switches could cause resequencing of packets if TCP were more 141 robust. There has been work proposed in the literature 142 explicitly to ensure that packet ordering is maintained in such 143 switches [KM02]. Also, link-layer mechanisms that attempt to 144 recover from packet corruption by retransmitting could be 145 allowed to reorder packets and, hence, increase the chances of 146 local loss repair rather than relying on TCP to repair the loss 147 (and, needlessly reduce its sending rate). Other examples are 148 multi-path routing, high-delay satellite links and some of the 149 schemes proposed for differentiated services architecture. By 150 making TCP more robust to non-congestion events, TCP-NCR may 151 open the design space of the future Internet components. 153 In this document we specify a set of sender modifications to provide 154 Non-Congestion Robustness (NCR) to TCP. In particular, these changes 155 are built on top of TCP with selective acknowledgments (SACKs) 156 [RFC2018] and the SACK-based loss recovery scheme given in [RFC3517], 157 since SACK is widely deployed at this point ([MAF04] indicates that 158 68% of web servers and 88% of web clients utilize SACK as of spring, 159 2004). 161 The remainder of this document is organized as follows. In Section 162 2, we specify the TCP-NCR algorithm. Section 3 provides a brief 163 overview of the benefits of TCP-NCR, while Section 4 discusses the 164 drawbacks of TCP-NCR. Section 5 discusses related work. Section 6 165 discusses security concerns. 167 2. Algorithm 169 The TCP-NCR modifications make two fundamental changes to the way 170 [RFC3517] currently operates, as follows. 172 First, the trigger for retransmitting a segment is changed from three 173 duplicate ACKs [RFC2581,RFC3517] to a congestion window's worth of 174 duplicate ACKs. This provides more time for packet reordering to 175 "work itself out" before the TCP sender infers that a segment has 176 been lost and needs retransmitted. Setting the retransmission point 177 is a balancing act. On the one hand, if the trigger is too 178 aggressive (as is sometimes the situation in current TCP stacks using 179 three duplicate acknowledgments to trigger loss recovery), the TCP 180 sender cannot accurately disambiguate loss from reordering. On the 181 other hand, waiting too long to decide to use fast retransmit risks 182 relying on the costly retransmission timeout (RTO) mechanism 183 [RFC2988]. Using a congestion window's worth of duplicate ACKs 184 provides a reasonable tradeoff because the delay involved (roughly 185 one RTT) is strictly less than the RTO and there is enough data in 186 the pipe to generate the number of duplicate ACKs required to trigger 187 a retransmission (given the extended version of Limited Transmit 188 [RFC3042] specified below). 190 Second, TCP-NCR decouples initial congestion control decisions from 191 retransmission decisions, in some cases delaying congestion control 192 changes relative to TCP's current behavior defined in [RFC2581]. The 193 algorithm provides two alternatives for extending Limited Transmit. 194 The two variants of extended Limited Transmit are: 196 Careful Limited Transmit: 198 This variant calls for reducing the sending rate at 199 approximately the same time [RFC2581] implementations reduce 200 the congestion window, while at the same time withholding a 201 retransmission (and the final congestion determination) for 202 approximately one RTT. 204 Aggressive Limited Transmit: 206 This variant calls for maintaining the sending rate in the 207 face of duplicate ACKs until TCP concludes a segment is lost 208 and needs to be retransmitted. (which, per the above, TCP-NCR 209 delays by one RTT when compared with current loss recovery 210 schemes). 212 TCP-NCR implementation MUST use either Careful Limited Transmit or 213 Aggressive Limited Transmit. 215 A constant MUST be set depending on which variant of extended Limited 216 Transmit is used, as follows: 218 Careful Limited Transmit: 220 LT_F = 2/3 222 Aggressive Limited Transmit: 224 LT_F = 1/2 226 This constant reflects the fraction of outstanding data that must be 227 ACKed before a retransmission is triggered. Since NCR's goal is to 228 wait roughly one RTT to retransmit, the fraction reflects the 229 different number of segments that will be transmitted during extended 230 Limited Transmit by the two schemes (and therefore their 231 aggressiveness). 233 The TCP-NCR modifications specified in this document lend themselves 234 to incremental deployment. Only the TCP implementation on the sender 235 side requires modification. The changes themselves are modest. 236 However, as will be discussed below, availability of additional 237 buffer space at the receiver will help maximize the benefits of using 238 TCP-NCR but are not strictly necessary. 240 The following algorithms depend on the notions provided by [RFC3517] 241 and we assume the reader is familiar with the terminology given in 242 [RFC3517]. The TCP-NCR algorithm can be adapted to alternate SACK- 243 based loss recovery schemes. [BR04,BSRV04] outline non-SACK-based 244 algorithms, however, we do not specify those algorithms in this 245 document and do not recommend them due to both the complexity and 246 security implications of having only a gross understanding of the 247 number of outstanding segments in the network. 249 A TCP connection using the Nagle algorithm [RFC896,RFC1122] MAY 250 employ the TCP-NCR algorithm. If a TCP implementation does implement 251 TCP-NCR the implementation MUST follow the various specifications 252 provides in sections 2.1 - 2.4. If the Nagle algorithm is not being 253 used there is no way to accurately calculate the number of 254 outstanding segments in the network (and, therefore, no good way to 255 derive an appropriate duplicate ACK threshold). A TCP connection 256 that does not employ the Nagle algorithm MAY use TCP-NCR if the TCP 257 implementation tracks the sequence numbers transmitted in each 258 segment and the following algorithm is carefully adapted. 260 2.1. Initialization 262 When entering a period of loss / reordering detection and Extended 263 Limited Transmit a TCP-NCR MUST initialize several state variables. 264 A TCP MUST enter Extended Limited Transmit upon receiving the first 265 ACK with a SACK block after the reception of an ACK that (a) did not 266 contain SACK information and (b) did increase the connection's 267 cumulative ACK point. The initializations are: 269 (I.1) Save the current FlightSize. 271 FlightSizePrev = FlightSize 273 (I.2) Set a variable for tracking the number of segments for which 274 an ACK does not trigger a transmission during Careful Limited 275 Transmit. 277 Skipped = 0 279 (I.3) Set DupThresh (from [RFC3517]) based on the size of the 280 current FlightSize. 282 DupThresh = max (LT_F * (FlightSize / SMSS),3) 284 Note: We keep the lower bound of DupThresh = 3 from 285 [RFC2581,RFC3517]. 287 In addition to the above steps, the incoming ACK MUST be processed 288 with the E series of steps in section 2.3. 290 2.2. Terminating Extended Limited Transmit and Preventing Bursts 292 Extended Limited Transmit MUST be terminated at the start of loss 293 recovery as outlined in section 2.4. 295 The arrival of an ACK that advances the cumulative ACK point before 296 loss recovery is triggered signals that the series of duplicate ACKs 297 were caused by reordering and not congestion. Therefore, the receipt 298 of an ACK that extends the cumulative ACK point MUST terminate 299 Extended Limited Transmit. As described below, an ACK that also 300 contains SACK information will also trigger the beginning of a new 301 Extended Limited Transmit phase. Upon the termination of Extended 302 Limited Transmit, and especially when using the Careful variant, TCP- 303 NCR may be in a situation where the entire cwnd is not being utilized 304 and therefore TCP-NCR will be prone to transmitting a burst of 305 segments into the network. Therefore, upon exiting Extended Limited 306 Transmit the following steps MUST be taken. 308 When a TCP-NCR in the Extended Limited Transmit phase receives an ACK 309 that updates the cumulative ACK point (regardless of whether the ACK 310 contains SACK information), the following steps MUST be taken: 312 (T.1) cwnd = min (FlightSize + SMSS,FlightSizePrev) 314 This step ensures that cwnd is not grossly larger than the 315 amount of data outstanding --- a situation that would cause a 316 line rate burst. 318 (T.2) ssthresh = FlightSizePrev 320 This step provides TCP-NCR with a sense of "history". If step 321 (T.1) reduces cwnd below FlightSizePrev this step ensures that 322 TCP-NCR will slow start back to operating point in effect 323 before Extended Limited Transmit. 325 (T.3) Transmit previously unsent data as allowed by cwnd, 326 FlightSize, application data availability and the receiver's 327 advertised window. 329 (T.4) When the cumulative ACK also contains SACK information, the 330 initializations in steps (I.2) and (I.3) from section 331 2.1 MUST be taken (but, not step (I.1)) to re-start Extended 332 Limited Transmit. In addition, the series of steps in section 333 2.3 (the "E" steps) MUST be taken. 335 2.3. Extended Limited Transmit 337 On each ACK containing SACK information that arrives after TCP-NCR 338 has entered the Extended Limited Transmit phase (as outlined in 339 section 2.1) and before Extended Limited Transmit terminates, the 340 sender MUST use the following procedure. 342 (E.1) Use the SetPipe () procedure from [RFC3517] to set the "pipe" 343 variable (which represents the number of bytes still considered 344 "in the network"). 346 (E.2) If the following comparison holds and there are SMSS bytes of 347 previously unsent data available for transmission then 348 transmit one segment of SMSS bytes. 350 (pipe + Skipped) <= (FlightSizePrev - SMSS) 352 If the comparison does not hold or no new data can be 353 transmitted (due to lack of data from the application or the 354 advertised window limit), skip to step (E.6). 356 (E.3) Increment pipe by SMSS bytes. 358 (E.4) If using Careful Limited Transmit, increment Skipped by SMSS 359 bytes to ensure that the next SMSS bytes of SACKed data 360 processed do not trigger a Limted Transmit transmission (since 361 the goal of Careful Limited Transmit is to send upon the 362 reception of every second duplicate ACK). 364 (E.5) Return to step (E.2) to ensure that as many bytes as 365 appropriate are transmitted. This provides robustness to ACK 366 loss that can be (largely) compensated for using SACK 367 information. 369 (E.6) Reset DupThresh via: 371 DupThresh = max (LT_F * (FlightSize / SMSS),3) 373 where FlightSize is the total number of bytes that have not 374 been cumulatively acknowledged. 376 2.4 Entering Loss Recovery 378 When a segment is deemed lost via the algorithms in [RFC3517], 379 Extended Limited Transmit MUST be terminated, leaving the 380 algoritms in [RFC3517] to govern TCP's behavior. One slight 381 change to [RFC3517] MUST be made, however. In section 5, step 382 (2) of [RFC3517] MUST be changed to: 384 (2) ssthresh = cwnd = (FlightSizePrev / 2) 386 This ensures that the congestion control modifications are made 387 with respect to the amount of data in the network before 388 FlightSize was increased by Extended Limited Transmit. 390 3. Advantages 392 The major advantages of TCP-NCR are two-fold. As discussed in 393 section 1, TCP-NCR will open up the design space for network 394 applications and components that are currently constrained by TCP's 395 lack of robustness to packet reordering. The second advantage is in 396 terms of an increase in TCP performance. 398 [BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP- 399 NCR algorithm specified in this document, called TCP-DCR (Delayed 400 Congestion Response). The paper shows that TCP-DCR aids performance 401 in comparison to unmodified TCP in the presence of packet reordering. 402 In addition, the extended version of [BR04] presents results based on 403 emulations involving Linux (kernel 2.4.24). These results show that 404 the performance of TCP-DCR is similar to Linux's native 405 implementation that seeks to "undo" wrong decisions based on DSACK 406 [RFC2883] feedback (similar to the schemes outlined in [ZKFP03]) when 407 packets are reordered by less than one RTT. The advantages of using 408 TCP-DCR over the DSACK-based scheme is that the DSACK-based scheme 409 tries to estimate the exact amount of reordering in the network using 410 fairly complex algorithms, whereas TCP-DCR achieves similar results 411 with less complicated modifications. 413 In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow 414 for the improvement of other parts of the system. For example, these 415 papers show that increasing TCP's robustness to packet reordering 416 allows for a novel wireless ARQ mechanism to be added at the link- 417 layer. The added robustness of the link-layer to channel errors, in 418 turn, increases TCP performance by not requiring TCP to retransmit 419 packets that were dropped due to corruption (and, hence, also 420 prevents TCP from needlessly reducing the sending rate when 421 retransmitting these segments). 423 4. Disadvantages 425 While we note that all of the changes outlined above are implemented 426 in the sender, the receiver also potentially has a part to play. In 427 particular, TCP-NCR increases the receiver's buffering requirement by 428 up to an extra cwnd -- in the case of the TCP sender using Aggressive 429 Limited Transmit and actual loss occurring in the network. 430 Therefore, to maximize the benefits from TCP-NCR receivers should 431 advertise a large window to absorb the extra out-of-order traffic. In 432 the case that the additonal buffer requirements are not met, the use 433 of the above algorithm takes into account the reduced advertised 434 window, resulting in slighlty reduced robustness to reordering. (The 435 worst case robustness of cwnd/2 still offers an improvement over 436 existing [RFC2581] implementations.) 438 In addition, using TCP-NCR could delay the delivery of data to the 439 application by up to one RTT because the fast retransmission point is 440 delayed by roughly one RTT in TCP-NCR. Applications that are 441 sensitive to such delays should turn off the TCP-NCR option. 443 Finally, the use of TCP-NCR makes the recovery from congestion events 444 sluggish. While the simulation study presented in [BR04,BSRV04] shows 445 that this does not have a significant impact further experimentation 446 on the real Internet is required to verify that result. 448 5. Related Work 450 Over the past few years, several solutions have been proposed to 451 improve the performance of TCP in the face of segment reordering. 452 These schemes generally fall into one of two categories (with some 453 overlap): mechanisms that try to prevent spurious retransmits from 454 happening and mechanisms that try to detect spurious retransmits and 455 "undo" the needless congestion control state changes that have been 456 taken. 458 [BA02,ZKFP03] attempt to prevent segment reordering from triggering 459 spurious retransmits by using various algorithms to approximate the 460 duplicate ACK threshold required to disambiguate loss and reordering 461 over the given network path. TCP-NCR similarly tries to prevent 462 spurious retransmits. However, TCP-NCR takes a simplified approach 463 compared to those in [BA02,ZKFP03] in that TCP-NCR simply delays 464 retransmission by a fixed amount (in comparison to standard TCP), 465 while the other schemes use relatively complex algorithms in an 466 attempt to derive a more precise value for DupThresh that depends on 467 the network conditions. While TCP-NCR offers simplicity the other 468 schemes may offer more precision such that applications would not be 469 forced to wait as long for their retransmissions. 471 On the other hand, several schemes have been developed to detect and 472 mitigate needless retransmissions after the fact. 473 [RFC3522,RFC3708,BA02,LG04,SK04] present algorithms to detect 474 spurious retransmits and mitigate the changes these events made to 475 the congestion control state. TCP-NCR could be used in conjunction 476 with these algorithms, with TCP-NCR attempting to prevent spurious 477 retransmits and some other scheme kicking in if the prevention 478 failed. In addition, we note that TCP-NCR is concentrated on 479 preventing spurious fast retransmits and some of the above algorithms 480 also attempt to detect and mitigate spurious timeout-based 481 retransmits. 483 6. Security Considerations 485 We do not believe there are security implications involved with TCP- 486 NCR over and above those for general TCP congestion control 487 [RFC2581]. In particular, the Extended Limited Transmit algorithms 488 have been specifically designed to not be susceptible to the sorts of 489 ACK splitting attacks TCP's general TCP congestion control is 490 vulnerable to (as discussed in [RFC3465]. 492 8. Acknowledgements 494 Sally Floyd, Nauzad Sadry and Nitin Vaidya as well as feedback from 495 from the TCPM working group have contributed significantly to this 496 document. Our thanks to all! 498 9. Normative References 500 [RFC793] J. Postel, "Transmission Control Protocol", RFC 793, 501 September 1981. 503 [RFC2018] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP 504 selective acknowledgment options," Internet RFC 2018. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC2581] M. Allman, V. Paxson, and W. Stevens, "TCP Congestion 510 Control", RFC 2581, April 1999. 512 [RFC3042] M. Allman, H. Balakrishnan and S. Floyd, "Enhancing TCP's 513 Loss Recovery Using Limited Transmit", RFC 3042, January 2001. 515 [RFC3517] E. Blanton, M. Allman, K. Fall and L. Wang, "A Conservative 516 Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for 517 TCP", RFC 3517, April 2003. 519 9. Informative References 521 [BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet 522 Reordering," ACM Computer Communication Review, January 2002. 524 [BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering 525 is not pat hological network behavior," IEEE/ACM Transactions on 526 Networking, December 1999. 528 [BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making 529 TCP Robust to Non-Congestion Events", In the Proceedings of 530 Networking 2004 conference, May 2004. Extended version available as 531 tech report TAMU-ECE-2003-04. 533 [BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and 534 Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating Wireless 535 Channel Errors", To appear in IEEE Transactions on Mobile Computing 537 [GPL04] Ladan Gharai, Colin Perkins and Tom Lehman, "Packet 538 Reordering, High Speed Networks and Transport Protocol Performance", 539 ICCCN 2004, October 2004. 541 [Jac88] V. Jacobson, "Congestion Avoidance and Control", Computer 542 Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. 543 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 545 [JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. 546 Towsley, "Measurement and Classification of Out-of-Sequence Packets 547 in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003. 549 [KM02] I. Keslassy and N. McKeown, "Maintaining packet order in 550 twostage switche s," Proceedings of the IEEE Infocom, June 2002 552 [LG04] R. Ludwig, A. Gurtov, "The Eifel Response Algorithm for TCP", 553 Internet-Draft draft-ietf-tsvwg-tcp-eifel-response-06.txt (work in 554 progress). September 2004. 556 [MAF04] A. Medina, M. Allman, S. Floyd. Measuring Interactions 557 Between Transport Protocols and Middleboxes. ACM SIGCOMM/USENIX 558 Internet Measurement Conference, Taormina, Sicily, Italy, October 559 2004. 561 [NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/ 563 [Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings 564 of ACM SIGCOMM, September 1997. 566 [RFC896] J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 567 896, January 1984. 569 [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication 570 Layers", RFC 1122, October 1989. 572 [RFC2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis and Matt 573 Podolsky, "An Extension to the Selective Acknowledgement (SACK) 574 Option for TCP," RFC 2883, July 2000. 576 [RFC2988] V. Paxson and M. Allman, "Computing TCP's Retransmission 577 Timer", RFC 2988, November 2000. 579 [RFC3465] M. Allman. TCP Congestion Control with Appropriate Byte 580 Counting (ABC), February 2003. RFC 3465. 582 [RFC3522] R. Ludwig and M. Meyer, "The Eifel Detection Algorithm for 583 TCP," RFC 3522, April 2003. 585 [RFC3708] E. Blanton and M. Allman, "Using TCP Duplicate Selective 586 Acknowledgement (DSACKs) and Stream Control Transmission Protocol 587 (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect 588 Spurious Retransmissions", RFC 3708, February 2004. 590 [SK04] P. Sarolahti, M. Kojo, "Forward RTO-Recovery (F-RTO): An 591 Algorithm for Detecting Spurious Retransmission Timeouts with TCP and 592 SCTP", Internet-Draft draft-ietf-tcpm-frto-02.txt (work in progress). 593 November 2004. 595 [ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, RR-TCP: A 596 Reordering-Robust TCP with DSACK, in Proceedings of the Eleventh IEEE 597 International Conference on Networking Protocols (ICNP 2003), 598 Atlanta, GA, November, 2003. 600 13. Author's Addresses 602 Sumitha Bhandarkar 603 Dept. of Elec. Engg. 604 214 ZACH 605 College Station, TX 77843-3128 606 Phone: (512) 468-8078 607 Email: sumitha@tamu.edu 608 URL : http://students.cs.tamu.edu/sumitha/ 610 A. L. Narasimha Reddy 611 Professor 612 Dept. of Elec. Engg. 613 315C WERC 614 College Station, TX 77843-3128 615 Phone : (979) 845-7598 616 Email : reddy@ee.tamu.edu 617 URL : http://ee.tamu.edu/~reddy/ 619 Mark Allman 620 ICSI Center for Internet Research 621 1947 Center Street, Suite 600 622 Berkeley, CA 94704-1198 623 Phone: (216) 243-7361 624 Email: mallman@icir.org 625 URL: http://www.icir.org/mallman/ 626 Ethan Blanton 627 Purdue University Computer Sciences 628 1398 Computer Science Building 629 West Lafayette, IN 47907 630 EMail: eblanton@cs.purdue.edu 632 Intellectual Property Statement 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed 636 to pertain to the implementation or use of the technology described 637 in this document or the extent to which any license under such 638 rights might or might not be available; nor does it represent that 639 it has made any independent effort to identify any such rights. 640 Information on the procedures with respect to rights in RFC 641 documents can be found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use 646 of such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository 648 at http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at 654 ietf-ipr@ietf.org. 656 Disclaimer of Validity 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Copyright Statement 668 Copyright (C) The Internet Society (2005). This document is subject 669 to the rights, licenses and restrictions contained in BCP 78, and 670 except as set forth therein, the authors retain all their rights. 672 Acknowledgment 673 Funding for the RFC Editor function is currently provided by the 674 Internet Society.