idnits 2.17.1 draft-ietf-tcpimpl-cong-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 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. ** There are 2 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-floyd-incr-init-win is -02, but you're referring to -03. ** Downref: Normative reference to an Experimental draft: draft-floyd-incr-init-win (ref. 'AFP98') -- Possible downref: Non-RFC (?) normative reference: ref. 'FF96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Flo94' -- Possible downref: Normative reference to a draft: ref. 'HTH98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac88' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac90' -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96b' ** Obsolete normative reference: RFC 793 (ref. 'Pos81') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ste94' ** Obsolete normative reference: RFC 2001 (ref. 'Ste97') (Obsoleted by RFC 2581) -- Possible downref: Non-RFC (?) normative reference: ref. 'WS95' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCP Implementation Working Group W. Stevens 2 INTERNET DRAFT Consultant 3 File: draft-ietf-tcpimpl-cong-control-00.txt M. Allman 4 NASA Lewis/Sterling Software 5 V. Paxson 6 LBNL 7 August, 1998 9 TCP Congestion Control 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as ``work in 22 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 This document defines TCP's four intertwined congestion control 33 algorithms: slow start, congestion avoidance, fast retransmit, and 34 fast recovery. In addition, the document specifies how TCP should 35 begin transmission after a relatively long idle period, as well as 36 discussing various acknowledgment generation methods. 38 1 Introduction 40 This document specifies four TCP [Pos81] congestion control 41 algorithms: slow start, congestion avoidance, fast retransmit and 42 fast recovery. These algorithms were devised in [Jac88] and 43 [Jac90]. Their use with TCP is required by [Bra89]. 45 This document is an update of [Ste97]. In addition to specifying 46 the congestion control algorithms, this document specifies what TCP 47 connections should do after a relatively long idle period, as well 48 as specifying and clarifying some of the issues pertaining to TCP 49 ACK generation. 51 Note that [Ste94] provides examples of these algorithms in action 52 and [WS95] provides an explanation of the source code for the BSD 53 implementation of these algorithms. 55 This document is organized as follows. Section 2 provides various 56 definitions which will be used throughout the paper. Section 3 57 provides a specification of the congestion control algorithms. 58 Section 4 outlines concerns related to the congestion control 59 algorithms and finally, section 5 outlines security considerations. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [Bra97]. 65 2 Definitions 67 This section provides the definition of several terms that will be 68 used throughout the remainder of this document. 70 SEGMENT: 71 A segment is ANY TCP/IP data or acknowledgment packet (or both). 73 MAXIMUM SEGMENT SIZE (MSS): 74 The MSS is the largest segment size that can be used. The size 75 does not include the TCP/IP headers and options. 77 FULL-SIZED SEGMENT: 78 A segment that contains the maximum number of data bytes 79 permitted (i.e., a segment containing MSS bytes of data). 81 RECEIVER WINDOW (rwnd) 82 The most recently advertised receiver window. 84 CONGESTION WINDOW (cwnd): 85 A TCP state variable that limits the amount of data a TCP can 86 send. At any given time, a TCP MUST NOT send data with a 87 sequence number higher than the sum of the highest acknowledged 88 sequence number and the minimum of cwnd and rwnd. 90 INITIAL WINDOW (IW): 91 The initial window is the size of the sender's congestion window 92 when a connection is established. 94 LOSS WINDOW (LW): 95 The loss window is the size of the congestion window after a TCP 96 sender detects loss using its retransmission timer. 98 RESTART WINDOW (RW): 99 The restart window is the size of the congestion window after a 100 TCP restarts transmission after an idle period. 102 3 Congestion Control Algorithms 104 This section defines the four congestion control algorithms: slow 105 start, congestion avoidance, fast retransmit and fast recovery, 106 developed in [Jac88] and [Jac90]. In some situations it may be 107 beneficial for a TCP sender to be more conservative than the 108 algorithms allow, however a TCP MUST NOT be more aggressive than the 109 following algorithms allow (that is, MUST NOT send data when the 110 value of cwnd computed by the following algorithms would not allow 111 the data to be sent). 113 3.1 Slow Start and Congestion Avoidance 115 The slow start and congestion avoidance algorithms MUST be used by a 116 TCP sender to control the amount of outstanding data being injected 117 into the network. To implement these algorithms, two variables are 118 added to the TCP per-connection state. The congestion window (cwnd) 119 is a sender-side limit on the amount of data the sender can transmit 120 into the network before receiving an acknowledgment (ACK), while the 121 receiver's advertised window (rwnd) is a receiver-side limit on the 122 amount of outstanding data. The minimum of cwnd and rwnd governs 123 data transmission. 125 Another state variable, the slow start threshold (ssthresh), is used 126 to determine whether the slow start or congestion avoidance 127 algorithm is used to control data transmission, as discussed below. 129 Beginning transmission into a network with unknown conditions 130 requires TCP to slowly probe the network to determine the available 131 capacity, in order to avoid congesting the network with an 132 inappropriately large burst of data. The slow start algorithm is 133 used for this purpose at the beginning of a transfer, or after 134 repairing loss detected by the retransmission timer. 136 IW, the initial value of cwnd, MUST be less than or equal to MSS 137 bytes. 139 We note that a non-standard, experimental TCP extension allows that 140 a TCP MAY use a larger initial window (IW), as defined in equation 1 141 [AFP98]: 143 IW = min (4*MSS, max (2*MSS, 4380 bytes)) (1) 145 With this extension, a TCP sender MAY use a 2 segment initial 146 window, regardless of the segment size, and 3 and 4 segment initial 147 windows MAY be used, provided the combined size of the segments does 148 not exceed 4380 bytes. We do NOT allow this change as part of the 149 standard defined by this document. However, we include discussion 150 of (1) in the remainder of this document as a guideline for those 151 experimenting with the change, rather than conforming to the present 152 standards for TCP congestion control. 154 The initial value of ssthresh MAY be arbitrarily high (for example, 155 some implementations use the size of the advertised window), but it 156 may be reduced in response to congestion. The slow start algorithm 157 is used when cwnd < ssthresh, while the congestion avoidance 158 algorithm is used when cwnd > ssthresh. When cwnd and ssthresh are 159 equal the sender may use either slow start or congestion avoidance. 161 During slow start, a TCP increments cwnd by at most MSS bytes for 162 each ACK received that acknowledges new data. Slow start ends when 163 cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted 164 above); or when cwnd reaches rwnd; or when congestion is observed. 166 During congestion avoidance, cwnd is incremented by 1 full-sized 167 segment per round-trip time (RTT). Congestion avoidance continues 168 until cwnd reaches the receiver's advertised window or congestion is 169 detected. One formula commonly used to update cwnd during 170 congestion avoidance is given in equation 2: 172 cwnd += MSS*MSS/cwnd (2) 174 This provides an acceptable approximation to the underlying 175 principle of increasing cwnd by 1 full-sized segment per RTT. (Note 176 that for a connection in which the receiver acknowledges every data 177 segment, (2) proves slightly more aggressive than 1 segment per RTT, 178 and for a receiver acknowledging every-other packet, (2) is less 179 aggressive.) 181 Implementation Note: Since integer arithmetic is usually used in TCP 182 implementations, the formula given in equation 2 can fail to 183 increase cwnd when the congestion window is very large (larger than 184 MSS*MSS). If the above formula yields 0, the result SHOULD be 185 rounded up to 1 byte. 187 Implementation Note: older implementations have an additional 188 additive constant on the right-hand side of (2). This is incorrect 189 and can actually lead to diminished performance [PAD+98]. 191 Another acceptable way to increase cwnd during congestion avoidance 192 is to count the number of bytes that have been acknowledged by ACKs 193 for new data. (A drawback of this implementation is that it 194 requires maintaining an additional state variable.) When the number 195 of bytes acknowledged reaches cwnd, then cwnd can be incremented by 196 up to MSS bytes. Note that during congestion avoidance, cwnd MUST 197 NOT be increased by more than the larger of either 1 full-sized 198 segment per RTT, or the value computed using equation 2. 200 Implementation Note: some implementations maintain cwnd in units of 201 bytes, while others in units of full-sized segments. The latter 202 will find equation (2) difficult to use, and may prefer to use the 203 counting approach discussed in the previous paragraph. 205 When a TCP sender detects segment loss using the retransmission 206 timer, the value of ssthresh MUST be set to no more than the value 207 given in equation 3: 209 ssthresh = max (min (cwnd, rwnd) / 2, 2*MSS) (3) 211 Implementation Note: an easy mistake to make is to forget the inner 212 min() operation and simply use cwnd, which in some implementations 213 may incidentally increase well beyond rwnd. 215 Furthermore, upon a timeout cwnd MUST be set to no more than the 216 loss window, LW, which equals 1 full-sized segment (regardless of 217 the value of IW). Therefore, after retransmitting the dropped 218 segment the TCP sender uses the slow start algorithm to increase the 219 window from 1 full-sized segment to the new value of ssthresh, at 220 which point congestion avoidance again takes over in a fashion 221 identical to that for a connection's initial slow start. 223 3.3 Fast Retransmit/Fast Recovery 225 A TCP receiver SHOULD send an immediate duplicate ACK when an 226 out-of-order segment arrives. The purpose of this ACK is to inform 227 the sender that a segment was received out-of-order and which 228 sequence number is expected. From the sender's perspective, 229 duplicate ACKs can be caused by a number of network problems. 230 First, they can be caused by dropped segments. In this case, all 231 segments after the dropped segment will trigger duplicate ACKs. 232 Second, duplicate ACKs can be caused by the re-ordering of data 233 segments by the network (not a rare event along some network paths). 234 Finally, duplicate ACKs can be caused by replication of ACK or data 235 segments by the network. 237 The TCP sender SHOULD use the "fast retransmit" algorithm to detect 238 and repair loss, based on incoming duplicate ACKs. The fast 239 retransmit algorithm uses the arrival of 3 duplicate ACKs (i.e., 4 240 identical ACKs) as an indication that a segment has been lost. 241 After receiving 3 duplicate ACKs, TCP performs a retransmission of 242 what appears to be the missing segment, without waiting for the 243 retransmission timer to expire. 245 After the fast retransmit sends what appears to be the missing 246 segment, the "fast recovery" algorithm governs the transmission of 247 new data until a non-duplicate ACK arrives. The reason for not 248 performing slow start is that the receipt of the duplicate ACKs not 249 only tells the TCP that a segment has been lost, but also that 250 segments are leaving the network. In other words, since the 251 receiver can only generate a duplicate ACK when a segment has 252 arrived, that segment has left the network and is in the receiver's 253 buffer, so we know it is no longer consuming network resources. 254 Furthermore, since the ACK "clock" [Jac88] is preserved, the TCP 255 sender can continue to transmit new segments (although transmission 256 must continue using a reduced cwnd). 258 The fast retransmit and fast recovery algorithms are usually 259 implemented together as follows. 261 1. When the third duplicate ACK is received, set ssthresh to no 262 more than the value given in equation 3. 264 2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS. 265 This artificially "inflates" the congestion window by the number 266 of segments (three) that have left the network and which the 267 receiver has buffered. 269 3. For each additional duplicate ACK received, increment cwnd by 270 MSS. This artificially inflates the congestion window in order 271 to reflect the additional segment that has left the network. 273 4. Transmit a segment, if allowed by the new value of cwnd and the 274 receiver's advertised window. 276 5. When the next ACK arrives that acknowledges new data, set cwnd 277 to ssthresh (the value set in step 1). This is termed 278 "deflating" the window. 280 This ACK should be the acknowledgment elicited by the 281 retransmission from step 1, one RTT after the retransmission 282 (though it may arrive sooner in the presence of significant 283 out-of-order delivery of data segments at the receiver). 284 Additionally, this ACK should acknowledge all the intermediate 285 segments sent between the lost segment and the receipt of the 286 first duplicate ACK, if none of these were lost. 288 Implementing fast retransmit/fast recovery in this manner can lead 289 to a phenomenon which allows the fast retransmit algorithm to repair 290 multiple dropped segments from a single window of data [Flo94]. 291 However, in doing so, the size of cwnd is also reduced multiple 292 times, which reduces performance. The following steps MAY be taken 293 to reduce the impact of successive fast retransmits on performance. 295 A. After the third duplicate ACK is received follow step 1 above, 296 but also record the highest sequence number transmitted 297 (send_high). 299 B. Instead of reducing cwnd to ssthresh upon receipt of the first 300 non-duplicate ACK received (step 5), the sender should wait 301 until an ACK covering send_high is received. In addition, each 302 duplicate ACK received should continue to artificially inflate 303 cwnd by 1 MSS. 305 C. A non-duplicate ACK that does not cover send_high, followed by 3 306 duplicate ACKs should not reduce ssthresh or cwnd but SHOULD 307 trigger a retransmission. A non-duplicate ACK that does not 308 cover send_high SHOULD NOT cause any adjustment in cwnd. 310 4 Additional Considerations 312 4.1 Re-starting Idle Connections 314 A known problem with the TCP congestion control algorithms described 315 above is that they allow a potentially inappropriate burst of 316 traffic to be transmitted after TCP has been idle for a relatively 317 long period of time. After an idle period, TCP cannot use the ACK 318 clock to strobe new segments into the network, as all the ACKs have 319 drained from the network. Therefore, as specified above, TCP can 320 potentially send a cwnd-size line-rate burst into the network after 321 an idle period. 323 [Jac88] recommends that a TCP use slow start to restart transmission 324 after a relatively long idle period. Slow start serves to restart 325 the ACK clock, just as it does at the beginning of a transfer. This 326 mechanism has been widely deployed in the following manner. When 327 TCP has not received a segment for more than one retransmission 328 timeout, cwnd is reduced to the value of the restart window (RW) 329 before transmission begins. 331 For the purposes of this standard, we define RW = IW = 1 full-sized 332 segment. 334 We note that the non-standard experimental extension to TCP defined 335 in [AFP98] defines RW = min(IW, cwnd), with the definition of IW 336 adjusted per equation (1) above. 338 Using the last time a segment was received to determine whether or 339 not to decrease cwnd fails to deflate cwnd in the common case of 340 persistent HTTP connections [HTH98]. In this case, a WWW server 341 receives a request before transmitting data to the WWW browser. The 342 reception of the request makes the test for an idle connection fail, 343 and allows the TCP to begin transmission with a possibly 344 inappropriately large cwnd. 346 Therefore, a TCP SHOULD reduce cwnd to no more than RW before 347 beginning transmission if the TCP has not sent data in an interval 348 exceeding the retransmission timeout. 350 4.2 Acknowledgment Mechanisms 352 The delayed ACK algorithm specified in [Bra89] SHOULD be used by a 353 TCP receiver. When used, a TCP receiver MUST NOT excessively delay 354 acknowledgments. Specifically, an ACK MUST be generated for every 355 second full-sized segment. (This "MUST" is listed in [Bra89] in one 356 place as a SHOULD and another as a MUST; here we unambiguously state 357 it is a MUST.) Furthermore, an ACK SHOULD be generated for every 358 second segment regardless of size. Finally, an ACK MUST NOT be 359 delayed for more than 500 ms waiting on a second full-sized segment 360 to arrive. Out-of-order data segments SHOULD be acknowledged 361 immediately, in order to trigger the fast retransmit algorithm. 363 A TCP receiver MUST NOT generate more than one ACK for every 364 incoming segment. 366 TCP implementations that implement the selective acknowledgment 367 (SACK) option [MMFR96] are able to determine which segments have not 368 arrived at the receiver. Consequently, they can retransmit the lost 369 segments more quickly than TCPs without SACKs. This allows a TCP 370 sender to repair multiple losses in roughly one RTT after detecting 371 loss [FF96,MM96a,MM96b]. While no specific SACK-based recovery 372 algorithm has yet been standardized, any SACK-based algorithm should 373 follow the general principles embodied by the above algorithms. 374 First, as soon as loss is detected, ssthresh should be decreased per 375 equation (3). Second, in the RTT following loss detection, the 376 number of segments sent should be no more than half the number 377 transmitted in the previous RTT (i.e., before loss occurred). 378 Third, after the recovery period is finished, cwnd should be set to 379 the reduced value of ssthresh. The SACK-based algorithms outlined 380 in [FF96,MM96a,MM96b] adhere to these guidelines. 382 5. Security Considerations 384 This document requires a TCP to diminish its sending rate in the 385 presence of retransmission timeouts and the arrival of duplicate 386 acknowledgments. An attacker can therefore impair the performance 387 of a TCP connection by either causing data packets or their 388 acknowledgments to be lost, or by forging excessive duplicate 389 acknowledgments. Causing two congestion control events back-to-back 390 will often cut ssthresh to its minimum value of 2*MSS, causing the 391 connection to immediately enter the slower-performing congestion 392 avoidance phase. 394 The Internet to a considerable degree relies on the correct 395 implementation of these algorithms in order to preserve network 396 stability and avoid congestion collapse. An attacker could cause 397 TCP endpoints to respond more aggressively in the face of congestion 398 by forging excessive duplicate acknowledgments or excessive 399 acknowledgments for new data. Conceivably, such an attack could 400 drive a portion of the network into congestion collapse. 402 Acknowledgments 404 The four algorithms that are described were developed by Van 405 Jacobson. 407 Some of the text from this document is taken from "TCP/IP 408 Illustrated, Volume 1: The Protocols" by W. Richard Stevens 409 (Addison-Wesley, 1994) and "TCP/IP Illustrated, Volume 2: The 410 Implementation" by Gary R. Wright and W. Richard Stevens 411 (Addison-Wesley, 1995). This material is used with the permission 412 of Addison-Wesley. 414 Sally Floyd devised the algorithm presented in section 3.3 for 415 avoiding multiple cwnd cutbacks in the presence of multiple packets 416 lost from the same flight. Craig Partridge and Joe Touch 417 contributed a number of helpful suggestions. 419 References 421 [AFP98] M. Allman, S. Floyd, C. Partridge, Increasing TCP's Initial 422 Window Size, Internet-Draft draft-floyd-incr-init-win-03.txt. 423 May, 1998. (Work in progress). 425 [Bra89] B. Braden, ed., "Requirements for Internet Hosts -- 426 Communication Layers," RFC 1122, Oct. 1989. 428 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of 432 Tahoe, Reno and SACK TCP. Computer Communication Review, July 433 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. 435 [Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical 436 report, October 1994. 437 ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 439 [HTH98] Amy Hughes, Joe Touch, John Heidemann. Internet-Draft 440 draft-ietf-tcpimpl-restart-00.txt, March 1998. (Work in 441 progress). 443 [Jac88] V. Jacobson, "Congestion Avoidance and Control," Computer 444 Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. 445 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 447 [Jac90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm," 448 end2end-interest mailing list, April 30, 1990. 449 ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail. 451 [MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining TCP 452 Congestion Control," Proceedings of SIGCOMM'96, August, 1996, 453 Stanford, CA. Available from 454 http://www.psc.edu/networking/papers/papers.html 456 [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding 457 Parameters" Available from 458 http://www.psc.edu/networking/papers/FACKnotes/current. 460 [MMFR96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective 461 Acknowledgement Options", RFC 2018, October 1996. 463 [PAD+98] V. Paxson, M. Allman, S. Dawson, J. Griner, I. Heavens, 464 K. Lahey, J. Semke, B. Volz. Internet-Draft 465 draft-ietf-tcpimpl-prob-04.txt, August 1998. (Work in 466 progress). 468 [Pos81] J. Postel, Transmission Control Protocol, September 1981. 469 RFC 793. 471 [Ste94] W. R. Stevens, "TCP/IP Illustrated, Volume 1: The 472 Protocols", Addison-Wesley, 1994. 474 [Ste97] W. R. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 475 Retransmit, and Fast Recovery Algorithms", RFC 2001, January 476 1997. 478 [WS95] G. R. Wright, W. R. Stevens, "TCP/IP Illustrated, Volume 2: 479 The Implementation", Addison-Wesley, 1995. 481 Author's Address: 483 W. Richard Stevens 484 1202 E. Paseo del Zorro 485 Tucson, AZ 85718 486 520-297-9416 487 rstevens@kohala.com 488 http://www.kohala.com/~rstevens 490 Mark Allman 491 NASA Lewis Research Center/Sterling Software 492 21000 Brookpark Rd. MS 54-2 493 Cleveland, OH 44135 494 216-433-6586 495 mallman@lerc.nasa.gov 496 http://gigahertz.lerc.nasa.gov/~mallman 498 Vern Paxson 499 Network Research Group 500 Lawrence Berkeley National Laboratory 501 Berkeley, CA 94720 502 USA 503 510-486-7504 504 vern@ee.lbl.gov