idnits 2.17.1 draft-ietf-tcpimpl-newreno-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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 11 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2001], [MMFR96], [RFC2001-bis], [Hoe95]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 368: '... [RFC2001] specifies that "Out-of-order data segments SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1999) is 9164 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Hen98' is defined on line 440, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'C98' ** Obsolete normative reference: RFC 2001 (ref. 'F98') (Obsoleted by RFC 2581) -- Possible downref: Non-RFC (?) normative reference: ref. 'FF96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Flo94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hen98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hoe95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hoe96' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTH98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LM97' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS' -- Duplicate reference: RFC2001, mentioned in 'RFC2001', was also mentioned in 'F98'. ** Obsolete normative reference: RFC 2001 (Obsoleted by RFC 2581) == Outdated reference: A later version (-05) exists of draft-ietf-tcpimpl-cong-control-00 Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sally Floyd 3 INTERNET DRAFT ACIRI 4 draft-ietf-tcpimpl-newreno-02.txt Tom Henderson 5 U.C. Berkeley 6 February 1999 7 Expires: August 1999 9 The NewReno Modification to TCP's Fast Recovery Algorithm 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 RFC 2001 [RFC2001] documents the following four intertwined TCP 33 congestion control algorithms: Slow Start, Congestion Avoidance, Fast 34 Retransmit, and Fast Recovery. RFC 2001-bis [RFC2001-bis] explicitly 35 allows certain modifications of these algorithms, including 36 modifications that use the TCP Selective Acknowledgement (SACK) 37 option [MMFR96], and modifications that respond to ``partial 38 acknowledgments'' (ACKs which cover new data, but not all the data 39 outstanding when loss was detected) in the absence of SACK. This 40 document describes a specific algorithm for responding to partial 41 acknowledgments, referred to as NewReno. This response to partial 42 acknowledgments was first proposed by Janey Hoe in [Hoe95]. 44 1. Introduction 46 For the typical implementation of the TCP Fast Recovery algorithm 47 described in [RFC2001-bis] (first implemented in the 1990 BSD Reno 48 release, and referred to as the Reno algorithm in [FF96]), the TCP 49 data sender only retransmits a packet after a retransmit timeout has 50 occurred, or after three duplicate acknowledgements have arrived 51 triggering the Fast Retransmit algorithm. A single retransmit 52 timeout might result in the retransmission of several data packets, 53 but each invocation of the Reno Fast Retransmit algorithm leads to 54 the retransmission of only a single data packet. 56 Problems can arise, therefore, when multiple packets have been 57 dropped from a single window of data and the Fast Retransmit and Fast 58 Recovery algorithms are invoked. In this case, if the SACK option is 59 available, the TCP sender has the information to make intelligent 60 decisions about which packets to retransmit and which packets not to 61 retransmit during Fast Recovery. This document applies only for TCP 62 connections that are unable to use the TCP Selective Acknowledgement 63 (SACK) option. 65 In the absence of SACK, there is little information available to the 66 TCP sender in making retransmission decisions during Fast Recovery. 67 From the three duplicate acknowledgements, the sender infers a packet 68 loss, and retransmits the indicated packet. After this, the data 69 sender could receive additional duplicate acknowledgements, as the 70 data receiver acknowledges additional data packets that were already 71 in flight when the sender entered Fast Retransmit. 73 In the case of multiple packets dropped from a single window of data, 74 the first new information available to the sender comes when the 75 sender receives an acknowledgement for the retransmitted packet (that 76 is the packet retransmitted when Fast Retransmit was first entered). 77 If there had been a single packet drop, then the acknowledgement for 78 this packet will acknowledge all of the packets transmitted before 79 Fast Retransmit was entered (in the absence of reordering). However, 80 when there were multiple packet drops, then the acknowledgement for 81 the retransmitted packet will acknowledge some but not all of the 82 packets transmitted before the Fast Retransmit. We call this packet 83 a partial acknowledgment. 85 Along with several other suggestions, [Hoe95] suggested that during 86 Fast Recovery the TCP data sender respond to a partial acknowledgment 87 by inferring that the indicated packet has been lost, and 88 retransmitting that packet. This document describes a modification 89 to the Fast Recovery algorithm in Reno TCP that incorporates a 90 response to partial acknowledgements received during Fast Recovery. 91 We call this modified Fast Recovery algorithm NewReno, because it is 92 a slight but significant variation of the basic Reno algorithm. This 93 document does not discuss the other suggestions in [Hoe95] and 94 [Hoe96], such as a change to the ssthresh parameter during Slow- 95 Start, or the proposal to send a new packet for every two duplicate 96 acknowledgements during Fast Recovery. The version of NewReno in 97 this document also draws on other discussions of NewReno in the 98 literature [LM97]. 100 We do not claim that the NewReno version of Fast Recovery described 101 here is an optimal modification of Fast Recovery for responding to 102 partial acknowledgements, for TCPs that are unable to use SACK. 103 Based on our experiences with the NewReno modification in the NS 104 simulator [NS], we believe that this modification improves the 105 performance of the Fast Retransmit and Fast Recovery algorithms in a 106 wide variety of scenarios, and we are simply documenting it for the 107 benefit of the IETF community. We encourage the use of this 108 modification to Fast Recovery, and we further encourage feedback 109 about operational experiences with this or related modifications. 111 2. Definitions 113 This document assumes that the reader is familiar with the terms 114 MAXIMUM SEGMENT SIZE (MSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE 115 (FlightSize) defined in [RFC2001-bis]. FLIGHT SIZE is defined as in 116 [RFC2001-bis] as follows: 118 FLIGHT SIZE: 119 The amount of data that has been sent but not yet 120 acknowledged. 122 3. The Fast Retransmit and Fast Recovery algorithms in NewReno 124 The standard implementation of the Fast Retransmit and Fast Recovery 125 algorithms is given in [RFC2001-bis]. The NewReno modification of 126 these algorithms is given below. This NewReno modification differs 127 from the implementation in [RFC2001-bis] only in the introduction of 128 the variable "recover" in step 1, and in the response to a partial or 129 new acknowledgement in step 5. 131 1. When the third duplicate ACK is received, set ssthresh to no 132 more than the value given in equation 1 below. (This is 133 equation 3 from [RFC2001-bis]). 135 ssthresh = max (FlightSize / 2, 2*MSS) (1) 137 Record the highest sequence number transmitted in the 138 variable "recover". 140 2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS. 141 This artificially "inflates" the congestion window by the number 142 of segments (three) that have left the network and which the 143 receiver has buffered. 145 3. For each additional duplicate ACK received, increment cwnd by 146 MSS. This artificially inflates the congestion window in order 147 to reflect the additional segment that has left the network. 149 4. Transmit a segment, if allowed by the new value of cwnd and the 150 receiver's advertised window. 152 5. When an ACK arrives that acknowledges new data, this ACK could be 153 the acknowledgment elicited by the retransmission from step 2, or 154 elicited by a later retransmission. 156 If this ACK acknowledges all of the data up to and including 157 "recover", then the ACK acknowledges all the intermediate 158 segments sent between the original transmission of the lost 159 segment and the receipt of the third duplicate ACK. Set cwnd to 160 either (1) min (ssthresh, FlightSize + MSS); or (2) ssthresh, 161 where ssthresh is the value set in step 1; this is termed 162 "deflating" the window. (We note that "FlightSize" in step 1 163 referred to the amount of data outstanding in step 1, when Fast 164 Recovery was entered, while "FlightSize" in step 5 refers to the 165 amount of data outstanding in step 5, when Fast Recovery is 166 exited.) If the second option is selected, the implementation 167 should take measures to avoid a possible burst of data, in case 168 the amount of data outstanding in the network was much less than 169 the new congestion window allows [HTH98]. Clear the counter 170 recording the number of duplicate acknowledgements, exiting the 171 Fast Recovery procedure. 173 If this ACK does *not* acknowledge all of the data up to and 174 including "recover", then this is a partial ACK. In this case, 175 retransmit the first unacknowledged segment. Deflate the 176 congestion window by the amount of new data acknowledged, then 177 add back one MSS and send a new segment if permitted by the new 178 value of cwnd. This "partial window deflation" attempts to 179 ensure that, when Fast Recovery eventually ends, approximately 180 ssthresh amount of data will be outstanding in the network. Do 181 not clear the counter recording the number of duplicate 182 acknowledgements (i.e., do not exit the Fast Recovery procedure). 184 For the first partial ACK that arrives during Fast Recovery, also 185 reset the retransmit timer. 187 Note that in Step 5, the congestion window is deflated when a partial 188 acknowledgement is received. The congestion window was likely to 189 have been inflated considerably when the partial acknowledgement was 190 received. In addition, depending on the original pattern of packet 191 losses, the partial acknowledgement might acknowledge nearly a window 192 of data. In this case, if the congestion window was not deflated, 193 the data sender might be able to send nearly a window of data back- 194 to-back. 196 There are several possible variants to the simple response to partial 197 acknowledgements described above. First, there is a question of when 198 to reset the retransmit timer after a partial acknowledgement. This 199 is discussed further in Section 4 below. 201 There is a related question of how many packets to retransmit after 202 each partial acknowledgement. The algorithm described above 203 retransmits a single packet after each partial acknowledgement. This 204 is the most conservative alternative, in that it is the least likely 205 to result in an unnecessarily-retransmitted packet. A variant that 206 would recover faster from a window with many packet drops would be to 207 effectively Slow-Start, requiring less than N roundtrip times to 208 recover from N losses [Hoe96]. With this slightly-more-aggressive 209 response to partial acknowledgements, it would be advantageous to 210 reset the retransmit timer after each retransmission. Because we 211 have not experimented with this variant in our simulator, we do not 212 discuss this variant further in this document. 214 A third question involves avoiding multiple Fast Retransmits caused 215 by the retransmission of packets already received by the receiver. 216 This is discussed in Section 5 below. Avoiding multiple Fast 217 Retransmits is particularly important if more aggressive responses to 218 partial acknowledgements are implemented, because in this case the 219 sender is more likely to retransmit packets already received by the 220 receiver. 222 As a final note, we would observe that in the absence of the SACK 223 option, the data sender is working from limited information. One 224 could spend a great deal of time considering exactly which variant of 225 Fast Recovery is optimal for which scenario in this case. When the 226 issue of recovery from multiple dropped packets from a single window 227 of data is of particular importance, the best alternative would be to 228 use the SACK option. 230 4. Resetting the retransmit timer. 232 The algorithm in Section 3 resets the retransmit timer only after the 233 first partial ACK. In this case, if a large number of packets were 234 dropped from a window of data, the TCP data sender's retransmit timer 235 will ultimately expire, and the TCP data sender will invoke Slow- 236 Start. (This is illustrated on page 12 of [F98].) We call this the 237 Impatient variant of NewReno. 239 In contrast, the NewReno simulations in [FF96] illustrate the 240 algorithm described above, with the modification that the retransmit 241 timer is reset after each partial acknowledgement. We call this the 242 Slow-but-Steady variant of NewReno. In this case, for a window with 243 a large number of packet drops, the TCP data sender retransmits at 244 most one packet per roundtrip time. (This behavior is illustrated in 245 the New-Reno TCP simulation of Figure 5 in [FF96], and on page 11 of 246 [F98].) 248 For TCP implementations where the Retransmission Timeout Value (RTO) 249 is generally not much larger than the round-trip time (RTT), the 250 Impatient variant can result in a retransmit timeout even in a 251 scenario with a small number of packet drops. For TCP 252 implementations where the Retransmission Timeout Value (RTO) is 253 usually considerably larger than the round-trip time (RTT), the Slow- 254 but-Steady variant can remain in Fast Recovery for a long time when 255 multiple packets have been dropped from a window of data. Neither of 256 these variants are optimal; one possibility for a more optimal 257 algorithm might be one that recovered more quickly from multiple 258 packet drops, and combined this with the Slow-but-Steady variant in 259 terms of resetting the retransmit timers. We note, however, that 260 there is a limitation to the potential performance in this case in 261 the absence of the SACK option. 263 5. Avoiding Multiple Fast Retransmits 265 In the absence of the SACK option, a duplicate acknowledgement 266 carries no information to identify the data packet or packets at the 267 TCP data receiver that triggered that duplicate acknowledgement. The 268 TCP data sender is unable to distinguish between a duplicate 269 acknowledgement that results from a lost or delayed data packet, and 270 a duplicate acknowledgement that results from the sender's 271 retransmission of a data packet that had already been received at the 272 TCP data receiver. Because of this, multiple segment losses from a 273 single window of data can sometimes result in unnecessary multiple 274 Fast Retransmits (and multiple reductions of the congestion window) 275 [Flo94]. 277 With the Reno or NewReno Fast Retransmit and Fast Recovery 278 algorithms, the performance problems caused by multiple Fast 279 Retransmits are relatively minor (compared to the potential problems 280 with Tahoe TCP, which does not implement Fast Recovery). 281 Nevertheless, these unnecessary Fast Retransmits can occur with Reno 282 or NewReno TCP, particularly if a Retransmit Timeout occurs during 283 Fast Recovery. (This is illustrated for Reno on page 6 of [F98], and 284 for NewReno on page 8 of [F98].) With NewReno, the data sender 285 remains in Fast Recovery until either a Retransmit Timeout, or until 286 all of the data outstanding when Fast Retransmit was entered has been 287 acknowledged. Thus with NewReno, the problem of multiple Fast 288 Retransmits from a single window of data can only occur after a 289 Retransmit Timeout. 291 The following modification to the algorithms in Section 3 eliminates 292 the problem of multiple Fast Retransmits. (This modification is 293 called "bugfix" in [F98], and is illustrated on pages 7 and 9.) This 294 modification uses a new variable "send_high", whose initial value is 295 zero. After each retransmit timeout, the highest sequence number 296 transmitted so far is recorded in the variable "send_high". 298 If, after a retransmit timeout, the TCP data sender retransmits three 299 consecutive packets that have already been received by the data 300 receiver, then the TCP data sender will receive three duplicate 301 acknowledgements that do not acknowledge "send_high". In this case, 302 the duplicate acknowledgements are not an indication of a new 303 instance of congestion. They are simply an indication that the 304 sender has unnecessarily retransmitted at least three packets. 306 We note that if the TCP data sender receives three duplicate 307 acknowledgements that do not acknowledge "send_high", the sender does 308 not know whether these duplicate acknowledgements resulted from a new 309 packet drop or not. For a TCP that implements the bugfix described 310 in this section for avoiding multiple fast retransmits, the sender 311 does not infer a packet drop from duplicate acknowledgements in these 312 circumstances. As always, the retransmit timer is the backup 313 mechanism for inferring packet loss in this case. 315 The modification to Fast Retransmit for avoiding multiple Fast 316 Retransmits replaces Step 1 in Section 3 with Step 1A below. In 317 addition, the modification adds Step 6 below: 319 1A. When the third duplicate ACK is received, check to see if those 320 duplicate ACKs cover more than "send_high". If they do, then set 321 ssthresh to no more than the value given in equation 1, record 322 the highest sequence number transmitted in the variables 323 "recover" and "send_high", and go to Step 2. If the duplicate 324 ACKs don't cover send_high, then do nothing. That is, do not 325 enter the Fast Retransmit and Fast Recovery procedure, do not 326 change ssthresh, and do not go to Step 2 to retransmit the "lost" 327 segment. 329 Steps 2-5 are the same as those steps in Section 3 above. 331 6. After a retransmit timeout, record the highest sequence number 332 transmitted in the variable "send_high". Do not change the 333 variable "recover". 335 Step 1A above, in checking whether the duplicate ACKs cover *more* 336 than "send_high", is the Careful variant of this algorithm. Another 337 possible variant would be to require simply that the three duplicate 338 acknowledgements *cover* "send_high" before initiating another Fast 339 Retransmit. We call this the Less Careful variant to Fast 340 Retransmit. 342 There are two separate scenarios in which the TCP sender could 343 receive three duplicate acknowledgements acknowledging "send_high" 344 but no more than "send_high". One scenario would be that the data 345 sender transmitted four packets with sequence numbers higher than 346 "send_high", that the first packet was dropped in the network, and 347 the following three packets triggered three duplicate 348 acknowledgements acknowledging "send_high". The second scenario 349 would be that the sender unnecessarily retransmitted three packets 350 below "send_high", and that these three packets triggered three 351 duplicate acknowledgements acknowledging "send_high". In the absence 352 of SACK, the TCP sender in unable to distinguish between these two 353 scenarios. 355 For the Careful variant of Fast Retransmit, the data sender would 356 have to wait for a retransmit timeout in the first scenario, but 357 would not have an unnecessary Fast Retransmit in the second scenario. 358 For the Less Careful variant to Fast Retransmit, the data sender 359 would Fast Retransmit as desired in the first scenario, and would 360 unnecessarily Fast Retransmit in the second scenario. The NS 361 simulator has implemented the Less Careful variant of NewReno, and 362 the TCP implementation in Sun's Solaris 7 implements the Careful 363 variant. This document recommends the Careful variant given in Step 364 1A above. 366 6. Implementation issues for the data receiver. 368 [RFC2001] specifies that "Out-of-order data segments SHOULD be 369 acknowledged immediately, in order to trigger the fast retransmit 370 algorithm." Neal Cardwell has noted [C98] that some data receivers do 371 not send an immediate acknowledgement when they send a partial 372 acknowledgment, but instead wait first for their delayed 373 acknowledgement timer to expire. As [C98] notes, this severely 374 limits the potential benefit from NewReno by delaying the receipt of 375 the partial acknowledgement at the data sender. Our recommendation 376 is that the data receiver send an immediate acknowledgement for an 377 out-of-order segment, even when that out-of-order segment fills a 378 hole in the buffer. 380 7. Simulations 382 Simulations with NewReno are illustrated with the validation test 383 "tcl/test/test-all-newreno" in the NS simulator. The command 384 "../../ns test-suite-newreno.tcl reno" shows a simulation with Reno 385 TCP, illustrating the data sender's lack of response to a partial 386 acknowledgement. In contrast, the command "../../ns test-suite- 387 newreno.tcl newreno_B" shows a simulation with the same scenario 388 using the NewReno algorithms described in this paper. 390 The tests "../../ns test-suite-newreno.tcl newreno1_B0" and "../../ns 391 test-suite-newreno.tcl newreno1_B" show the Slow-but-Steady and the 392 Impatient variants of NewReno, respectively. 394 8. Conclusions 396 Our recommendation is that TCP implementations include the NewReno 397 modification to the Fast Recovery algorithm given in Section 3, along 398 with the modification for avoiding multiple Fast Retransmits given in 399 Section 5. The NewReno modification given in Section 3 can be 400 important even for TCP implementations that support the SACK option, 401 because the SACK option can only be used for TCP connections when 402 both TCP end-nodes support the SACK option. The NewReno modification 403 given in Section 3 implements the Impatient rather than the Slow-but- 404 Steady variant of NewReno. 406 While this document mentions several possible variations to the 407 NewReno algorithm, we have not explored all of these possible 408 variations, and therefore are unable to make recommendations about 409 some of them. Our belief is that the differences between any two 410 variants of NewReno are small compared to the differences between 411 Reno and NewReno. That is, the important thing is to implement 412 NewReno instead of Reno, for a TCP invocation without SACK; it is 413 less important exactly *which* variant of NewReno is implemented. 415 9. Acknowledgements 417 Many thanks to Mark Allman, Vern Paxson, Kacheong Poon, and Bernie 418 Volz for detailed feedback on this document. 420 10. References 422 [C98] Neal Cardwell, "delayed ACKs for retransmitted packets: ouch!". 423 November 1998. Email to the tcpimpl mailing list, Message-ID 424 "Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu", 425 archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". 427 [F98] Sally Floyd. Revisions to RFC 2001. Presentation to the 428 TCPIMPL Working Group, August 1998. URLs 429 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and 430 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf". 432 [FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of 433 Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996. 434 URL "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z". 436 [Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical 437 report, October 1994. URL 438 "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps". 440 [Hen98] Tom Henderson, Re: NewReno and the 2001 Revision. September 441 1998. Email to the tcpimpl mailing list, Message ID 442 "Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU", 443 archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". 445 [Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and 446 Avoidance Schemes. Master's Thesis, MIT, 1995. URL "http://ana- 447 www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps". 449 [Hoe96] J. Hoe, Improving the Start-up Behavior of a Congestion 450 Control Scheme for TCP. In ACM SIGCOMM, August 1996. URL 451 "http://www.acm.org/sigcomm/sigcomm96/program.html". 453 [HTH98] A. Hughes, J. Touch, J. Heidemann, Issues in TCP Slow-Start 454 Restart After Idle, Work in progress, March 1998. 456 [LM97] Dong Lin and Robert Morris, "Dynamics of Random Early 457 Detection", SIGCOMM 97, September 1997. URL 458 "http://www.acm.org/sigcomm/sigcomm97/program.html". 460 [MMFR96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective 461 Acknowledgement Options", RFC 2018, October 1996. 463 [NS] The UCB/LBNL/VINT Network Simulator (NS). URL "http://www- 464 mash.cs.berkeley.edu/ns/". 466 [RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 467 Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. 469 [RFC2001-bis] W. Stevens, M. Allman, and V. Paxson, "TCP Congestion 470 Control", draft-ietf-tcpimpl-cong-control-00.txt, August 1998. 472 11. Security Considerations 474 RFC 2001-bis discusses general security considerations concerning TCP 475 congestion control. This document describes a specific algorithm 476 that conforms with the congestion control requirements of RFC 477 2001-bis, and so those considerations apply to this algorithm, too. 478 There are no known additional security concerns for this specific 479 algorithm. 481 AUTHORS' ADDRESSES 483 Sally Floyd 484 AT&T Center for Internet Research at ICSI (ACIRI) 485 Phone: +1 (510) 642-4274 x189 486 Email: floyd@acm.org 487 URL: http://www-nrg.ee.lbl.gov/floyd/ 489 Tom Henderson 490 University of California at Berkeley 491 Phone: +1 (510) 642-8919 492 Email: tomh@cs.berkeley.edu 493 URL: http://www.cs.berkeley.edu/~tomh/ 495 This draft was created in February 1999. 496 It expires August 1999.