idnits 2.17.1 draft-kksjf-ecn-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-24) 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 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 == 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 Introduction 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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([Jacobson88,Jacobson90]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 1997) is 9657 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Jacobson88' on line 435 looks like a reference -- Missing reference section? 'Jacobson90' on line 439 looks like a reference -- Missing reference section? 'FJ93' on line 418 looks like a reference -- Missing reference section? 'RED-ietf-draft' on line 443 looks like a reference -- Missing reference section? 'RJ90' on line 453 looks like a reference -- Missing reference section? 'Floyd94' on line 423 looks like a reference -- Missing reference section? 'RFC 2001' on line 196 looks like a reference -- Missing reference section? 'RFC2001' on line 450 looks like a reference -- Missing reference section? 'Floyd97' on line 427 looks like a reference -- Missing reference section? 'FRED' on line 431 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force K. K. Ramakrishnan 2 INTERNET DRAFT AT&T Labs Research 3 draft-kksjf-ecn-00.txt Sally Floyd 4 LBNL 5 November 1997 6 Expires: May 1998 8 A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This note describes a proposed addition of ECN (Explicit Congestion 31 Notification) to IPv6 and to TCP. First we describe TCP's use of 32 packet drops as an indication of congestion. Next we argue that with 33 the addition of active queue management (e.g., RED) to the Internet 34 infrastructure, where routers detect congestion before the queue 35 overflows, routers are no longer limited to packet drops as an 36 indication of congestion, but could instead set an ECN bit in the 37 packet header, for ECN-capable transport protocols. We describe when 38 the ECN bit would be set in the routers, and describe what 39 modifications would be needed to TCP to make it ECN-capable. 40 Modifications to other transport protocols (e.g., unreliable unicast 41 or multicast, reliable multicast, other reliable unicast transport 42 protocols) could be considered as those protocols advance through the 43 standards process. 45 TCP's congestion control and avoidance algorithms are based on the 46 notion that the network is a black-box [Jacobson88, Jacobson90]. The 47 network's state of congestion or otherwise is determined by end- 48 systems probing for the network state, by gradually increasing the 49 load on the network (by increasing the window of packets that are 50 outstanding in the network) until the network becomes congested and a 51 packet is lost. Treating the network as a "black-box" and treating 52 loss as an indication of congestion in the network is appropriate for 53 pure best-effort data carried by TCP that has little or no 54 sensitivity to delay or loss of individual packets. In addition, 55 TCP's congestion management algorithms have techniques built-in (such 56 as fast retransmit and fast recovery) to minimize the impact of 57 losses from a throughput perspective. 59 However, these mechanisms are not intended to help applications that 60 are in fact sensitive to the delay or loss of one or more individual 61 packets. Interactive traffic such as telnet, web-browsing, and 62 transfer of audio and video data ("real-audio" and "real-video") can 63 be sensitive to packet losses (for unreliable data delivery such as 64 UDP) or to the increased latency of the packet caused by the need to 65 retransmit the packet after a loss (for reliable data delivery such 66 as TCP). 68 Since TCP determines the appropriate congestion window to use by 69 gradually increasing the window size until it experiences a dropped 70 packet, this causes the queues at the bottleneck router to build up. 71 With most packet drop policies at the router that are not sensitive 72 to the load placed by each individual flow, this means that some of 73 the packets of latency-sensitive flows are going to be dropped. 74 Active queue management mechanisms that detect congestion before the 75 queue overflows, and provide an indication of this congestion to TCP, 76 is desirable because it avoids some bad properties of dropping on 77 queue overflow, especially with drop-tail schemes. Drop tail 78 introduces synchronization of loss across multiple flows which is 79 undesirable. Indicating incipient congestion means that TCP does not 80 have to increase its window size up to the point where a router's 81 buffer is filled up. This can reduce queuing delays and avoid 82 synchronization, which are desirable characteristics. 84 2. Random Early Detection (RED) 86 Random Early Detection (RED) is a mechanism for active queue 87 management that has been proposed to detect incipient congestion 88 [FJ93], and is currently being deployed in the Internet backbone 89 [RED-ietf-draft]. Although RED is meant to be a general mechanism 90 using one of several alternatives for congestion indication, in the 91 current environment of the Internet RED is restricted to using packet 92 drops as a mechanism for congestion indication. By dropping packets 93 based on the average queue length exceeding a threshold, rather than 94 only when the queue overflows, RED maintains the average queue at a 95 smaller level, and improves the delay experienced by the flows. 96 However, when RED drops packets before the queue actually overflows, 97 RED is not forced by memory limitations to discard the packet. RED 98 could set an Explicit Congestion Notification bit in the packet 99 header instead of dropping the packet, if such a bit was provided in 100 the IP header and understood by the transport protocol. The use of 101 the Explicit Congestion Notification bit would allow the receiver(s) 102 to receive the packet, avoiding the potential for excessive delays 103 due to retransmissions after packet losses. 105 3. Explicit Congestion Notification 107 We propose that the Internet provide a congestion indication for 108 incipient congestion (as in RED and earlier work [RJ90]) where the 109 notification can sometimes be through marking packets rather than 110 dropping them. This would require an ECN field in the IP header with 111 two bits. The ECN-Capable bit would be set by the data sender to 112 indicate an ECN-capable transport protocol. The ECN bit would be set 113 by the router to indicate congestion to the end nodes. ([Floyd94] 114 outlines a scheme where a single bit could be overloaded to serve the 115 function of both the ECN-Capable bit and the ECN bit, but the two-bit 116 scheme is more straightforward to explain). We expect that routers 117 would provide the congestion indication on incipient congestion as 118 indicated by the average queue size, using the RED algorithms 119 suggested in [FJ93, RED-ietf-draft]. Routers that have a packet 120 arriving at a full queue would drop the packet, just as they do now. 122 The congestion control algorithms followed at the end-systems would 123 be essentially the same as the congestion control response to a 124 *single* dropped packet, for a transport protocol where a dropped 125 packet is used as an indication of congestion. For TCP in 126 particular, the source TCP would halve its congestion window "cwnd" 127 in response to an ECN indication received by the data receiver. 128 However, this action is done only once per window of data (i.e., at 129 most once per roundtrip time), to avoid reacting multiple times to 130 multiple indications of congestion within a roundtrip time. 132 4. Proposed Algorithm at the Router 134 We describe the proposed algorithm at the router in the context of 135 current router implementations. We assume that the router is capable 136 of implementing the probability computation for RED and uses a pure 137 packet drop mechanism (e.g., drop from front, drop from tail, or 138 random drop) whenever a packet arrives at a full queue. 140 When the router's buffer is not yet full and the router is prepared 141 to drop a packet to inform end nodes of incipient congestion, the 142 router should first check to see if the ECN-Capable bit is set in 143 that packet's IP header. If so, then instead of dropping the packet, 144 the router could instead set the ECN bit in the IP header. When more 145 severe congestion has occurred and the router's queue is full, then 146 the router has no choice but to drop some packet when a new packet 147 arrives. 149 The router determines it is congested if the AVERAGE length of any of 150 its queues where packets are waiting to be processed or transmitted 151 exceeds a threshold. We believe that the router should use the ECN 152 bit to notify that it is congested only when the *average* queue 153 length, rather than the instantaneous queue length, exceeds a 154 threshold. 156 There are potentially several alternatives for estimating the average 157 queue length and marking the ECN bit. Since there is considerable 158 effort involved already in implementing RED, we believe it is best to 159 leverage these efforts for ECN as well. One potential mechanism for 160 the averaging and marking is to perform functions similar to RED 161 queue management: RED uses an exponential moving average of the queue 162 size. When the average queue size goes above a lower threshold, 163 packets are marked with a probability of marking that increases with 164 the average queue size. (Packets that are not ECN-capable are 165 dropped instead of marked.) When the average queue size gets up to or 166 above a high threshold, all incoming packets should be dropped 167 (assuming that the router intends to control the average queue size 168 even in the presence of unresponsive traffic). 170 It is anticipated that when all of the source end-systems participate 171 in TCP's congestion management mechanisms or other compatible 172 congestion control, and respond to ECN by reducing their offered 173 load, packet losses would be relatively infrequent. Packet losses in 174 this case would occur primarily during transients and in the presence 175 of non-cooperating entities. 177 When a packet is received by a router with the ECN bit set indicating 178 that congestion was encountered upstream, then the bit is left 179 unchanged, and the packet transmitted as usual. 181 5. Support from the Transport Protocol 183 ECN requires support from the transport protocol, in addition to the 184 ECN field in the IPv6 packet header. For TCP, ECN requires two new 185 mechanisms: negotiation between the endpoints during setup to 186 determine if they are both ECN-capable, and an ECN-Notify bit in the 187 TCP header so that the data receiver can inform the data sender when 188 a packet has been received with the ECN bit set. The support 189 required from other transport protocols is likely to be different, 190 particular for unreliable or reliable multicast transport protocols, 191 and will have to be determined as other transport protocols are 192 brought to the IETF for standardization. The following sections 193 describe in detail the proposed TCP use of ECN. This is also 194 described in [Floyd94]. We assume that the source TCP uses the 195 current set of congestion control algorithms of Slow-start, Fast 196 Retransmit and Fast Recovery [RFC 2001]. 198 5.1. TCP Initialization 200 Initially, the source and destination TCPs exchange the desire and/or 201 capability to use ECN in the TCP connection setup phase. As a result 202 of the negotiation, the TCP sender indicates using the ECN-Capable 203 bit in the IPv6 header that the transport is capable and willing to 204 participate in ECN. This will indicate to the routers that they may 205 mark packets with the ECN bit, if they would like to use that as a 206 method of congestion notification. If the TCP connection does not 207 wish to use ECN notification, the sending TCP sets the ECN-Capable 208 bit equal to 0 (i.e., not set), and the TCP receiver ignores the ECN 209 bit in received packets. 211 5.2. The TCP Sender 213 For a connection that expects to use ECN, packets are transmitted 214 with the ECN-Capable bit set in the IP header (set to a "1"). If the 215 sender receives a TCP acknowledgement with the ECN-Notify bit set in 216 the TCP header, then the sender knows that congestion was encountered 217 in the network on the path from the sender to the receiver. The 218 indication of congestion should be treated just as a congestion loss 219 in non-ECN-Capable TCP. That is, the TCP source halves the congestion 220 window "cwnd" and reduces the slow start threshold "ssthresh". The 221 sending TCP does NOT increase the congestion window in response to 222 the receipt of an ACK packet with the ECN-Notify bit set. However, a 223 very important difference is that TCP does not react to ECN 224 congestion indications more than once every window of data (or more 225 loosely, more than once every round-trip time). If a response to the 226 ECN-Notify bit was made over the last round-trip time, based on the 227 window of packets, then the sending TCP doesn't respond to any 228 further ECN messages. If at time "t", the source TCP reacted to an 229 ECN, then it notes the packets that are outstanding at that time and 230 have not yet been acknowledged. Until all these packets are 231 acknowledged, say at time "u", the source TCP does not react to 232 another ECN indication of congestion. 234 In addition, when a TCP sender receives duplicate acks during the 235 time interval between "t" and "u", it does not reduce the congestion 236 window. The result is that decreases in the congestion window occur 237 at most once per roundtrip time. 239 When the TCP sender receives a packet with the ECN-Notify bit set, 240 and therefore reduces its congestion window, the sender does not need 241 to slow-start (as is done in Tahoe TCP in response to a packet drop) 242 or to stop sending packets for a period of time to allow the queue to 243 dissipate (as is done by Reno TCP for roughly half a round-trip time 244 in response to a packet drop). The ECN-Notify bit being set does not 245 indicate the urgent transient congestion state of a buffer overflow. 246 Incoming acknowledgements will still arrive to "clock out" outgoing 247 packets when allowed by the congestion window. 249 TCP follows existing algorithms for sending data packets in response 250 to incoming ACKs, multiple duplicate acknowledgements, or retransmit 251 timeouts [RFC2001]. 253 5.3. The TCP Receiver 255 At the destination end-system, when TCP receives a packet with the 256 ECN bit set in the IP header, TCP sets the ECN-Notify bit in the TCP 257 header in the returning ACK packet. We do not provide here any 258 notion of destination congestion, because this is already being 259 indicated in the receiver's advertised window. 261 The destination TCP continues to perform the duplicate ACK procedure 262 already specified - to generate a duplicate ACK when an out-of- 263 sequence packet is received. 265 If there is any ACK withholding implemented, as in current TCP 266 implementations where the TCP receiver often sends an ACK for two 267 arriving data packets, then the TCP destination will send the OR of 268 all the ECN bits of packets that the ACK is acknowledging. That is, 269 if any packet is received with the ECN bit set, then the ACK carries 270 the ECN-Notify bit set. 272 5.4. Congestion on the ACK-path 274 For the current generation of TCP congestion control algorithms, pure 275 acknowledgement packets (e.g., packets that do not contain any 276 accompanying data) should be sent with the ECN-capable bit off. 277 Current TCP receivers have no mechanisms for reducing traffic on the 278 ACK-path in response to congestion notification. Mechanisms for 279 responding to congestion on the ACK-path can be relegated as an area 280 for future research. (One simple possibility would be for the sender 281 to reduce its congestion window when it receives a pure ACK packet 282 with the ECN bit set). For current TCP implementations, a single 283 dropped ACK generally has only a very small effect on the TCP's 284 sending rate. 286 6. Summary of changes required in IPv6 and TCP 288 Two bits need to be specified in the IPv6 header, the ECN-Capable bit 289 and the ECN bit. The ECN-Capable bit set to "0" indicates that the 290 transport protocol will ignore the ECN bit. This is the default 291 value. The ECN-Capable bit set to "1" indicates that the transport 292 protocol is willing and able to participate in ECN. 294 The default value for the ECN bit is "0". The router sets the ECN 295 bit to "1" to indicate congestion to the end nodes. The ECN bit in a 296 packet header should never be reset by a router from "1" to "0". 298 TCP requires two changes, a negotiation phase during setup to 299 determine if both end nodes are ECN-capable, and a bit in the TCP 300 header (possibly one of the "reserved" bits in the TCP flags field) 301 as an ECN-Notify bit so that the receiver can inform the sender of a 302 packet received with the ECN bit set. 304 7. Non-relationship to ATM's EFCI indicator or Frame Relay's FECN 306 Since these ATM and Frame Relay mechanisms typically have been 307 defined without any notion of average queue size as the basis for 308 concluding that there is congestion, we believe that they provide a 309 very noisy signal. The interpretation we have here for ECN is NOT the 310 appropriate reaction for such a noisy signal of congestion 311 notification. It is our belief that such mechanisms would be phased 312 out over time within the ATM network. However, if the routers that 313 interface to the ATM network have a way of maintaining the average 314 queue at the interface, and use it to come to a conclusion that the 315 ATM subnet is congested or otherwise, they may use the ECN 316 notification that is defined here. 318 8. Non-compliance by the End Nodes 320 We believe that, for the most part, the fairness properties of TCP 321 will not be changed with the introduction of ECN. 323 A key issue concerns the vulnerability of ECN to non-compliant end- 324 nodes (i.e., end nodes that set the ECN-capable bit in packets, but 325 do not respond to the ECN bit itself). These concerns exist even in 326 non-ECN environments. An end-node could "turn off congestion 327 control" by not reducing its congestion window in response to packet 328 drops. We recognize that this is a concern for the current Internet. 329 It has been argued that routers will have to deploy mechanisms to 330 detect and differentially treat packets from non-compliant flows. It 331 is likely that techniques such as end-to-end per-flow scheduling and 332 isolation of one flow from another, potentially accompanied by end- 333 to-end reservations, could mitigate such effects. Such isolation 334 mechanisms could remove some of the more egregious effects of non- 335 compliance. 337 However, even in networks just restricted to packet losses as an 338 indication of congestion, several methods have been proposed to 339 identify and treat non-compliant or unresponsive flows. These 340 mechanisms would be equally applicable for identifying flows that do 341 not respond to ECN. If anything, routers would have a slightly 342 easier time identifying flows that do not respond to ECN. For 343 example, routers can observe packets arriving at the router with the 344 ECN bit set, as well as keeping note of packets that have the ECN bit 345 set at that router itself. 347 It has been argued that dropping packets in itself may be considered 348 a deterrrent for non-compliance. However, we believe that the packet 349 drop rates are likely to be reasonably low in environments where ECN 350 is deployed. The reduction in load due to packet drops to deal with 351 non-compliant nodes is likely to be small. The control of congestion 352 is more likely to come from end-nodes reacting to congestion - either 353 from responding to dropped packets or ECN Notify indications and 354 halving the window. ECN should be used at a router when the average 355 queue size is below some high threshold; when the average queue size 356 exceeds the high threshold, and therefore packet drop/marking rates 357 are higher, our recommendation is that routers drop packets, rather 358 then setting the ECN bit in packet headers. Thus, in scenarios with 359 low packet drop rates, the fact that the congestion control 360 indications are in the form of packet drops rather than ECN bits does 361 not significantly change the negative consequences on the compliant 362 flows because of some flow "turning off" congestion control. 364 We also do not believe that packet dropping itself is an effective 365 deterrent for non-compliance. Many flows that retransmit dropped 366 packets could have an incentive to maintain or even increase their 367 sending rate in response to packet drops, rather than decreasing 368 their sending rate, in the absence of mechanisms at the router to 369 provide a negative deterrance for such behavior. For example, flows 370 that use unreliable transport protocols could simply increase their 371 use of FEC in response to an increased packet drop rate, and might 372 choose increased FEC and no congestion control. We believe that the 373 effect of packet dropping as a deterrence for non-compliance with 374 congestion control mechanisms is quite small. The possibility of 375 non-compliant flows does not offer a compelling reason not to deploy 376 ECN. 378 9. Additional Considerations 380 Some care is required to handle the ECN and ECN-Capable bits 381 appropriately when packets are encapsulated and un-encapsulated for 382 tunnels. When the router at the end of the tunnel decapsulates the 383 packet, then the ECN bit in the encapsulating ('outside') header 384 should be ORed with the ECN bit in the encapsulated ('inside') header 385 that remains. Basically, a 1 in the encapsulating header should be 386 copied into the encapsulated header. 388 An additional issue concerns packets that have the ECN bit set at one 389 router, and are later dropped at another router. For the proposed 390 use for ECN in this paper (that is, for data packets for TCP), this 391 is not a concern, because end nodes detect dropped data packets, and 392 the congestion response of the end nodes to a dropped data packet is 393 at least as strong as the congestion response to a packet received 394 with the ECN bit set. This issue will have to be addressed if ECN 395 and ECN-Capable bits are used on pure ACK packets, because in current 396 implementations of TCP the drop of an ACK packet is not explicitly 397 detected by the end nodes. 399 If a packet with the ECN bit is later dropped due to corruption (bit 400 errors), the end node should still invoke congestion control, just as 401 TCP would today, to a dropped data packet. This issue would also 402 have to be addressed in future proposals for distinguishing between 403 packets dropped due to corruption and packets dropped due to 404 congestion. 406 10. Conclusions 408 Given the current effort to implement RED, we believe this is the 409 right time for router vendors to examine how to also implement 410 congestion avoidance mechanisms that do not depend on packet drops 411 alone. With the growth of applications and transports that are 412 sensitive to delay and loss of a single packet, depending on packet 413 loss as a normal congestion notification mechanism appears to be 414 insufficient (or at the very least, non-optimal). 416 REFERENCES 418 [FJ93] Floyd, S., and Jacobson, V., "Random Early Detection gateways 419 for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 420 N.4, August 1993, p. 397-413. URL 421 "ftp://ftp.ee.lbl.gov/papers/early.pdf". 423 [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM 424 Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. 425 URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". 427 [Floyd97] Floyd, S., and Fall, K., "Router Mechanisms to Support 428 End-to-End Congestion Control", Technical report, February 1997. URL 429 "ftp://ftp.ee.lbl.gov/papers/collapse.ps". 431 [FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", 432 SIGCOMM '97, September 1997. URL 433 "http://www.inria.fr/rodeo/sigcomm97/program.html#ab078". 435 [Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. 436 ACM SIGCOMM '88, pp. 314-329. URL 437 "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z". 439 [Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance 440 Algorithm", Message to end2end-interest mailing list, April 1990. 441 URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt". 443 [RED-ietf-draft] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. 444 Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, 445 L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, 446 "Recommendations on Queue Management and Congestion Avoidance in the 447 Internet", Internet draft draft-irtf-e2e-queue-mgt-00.txt, March 25, 448 1997. 450 [RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 451 Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. 453 [RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for 454 Congestion Avoidance in Computer Networks", ACM Transactions on 455 Computer Systems, Vol.8, No.2, pp. 158-181, May 1990. 457 SECURITY CONSIDERATIONS 459 Security issues are not discussed in this document. 461 AUTHORS' ADDRESSES 463 K. K. Ramakrishnan 464 AT&T Labs. Research 465 Phone: +1 (973) 360-8766 466 Email: kkrama@research.att.com 467 URL: http://www.research.att.com/info/kkrama 469 Sally Floyd 470 Lawrence Berkeley National Laboratory 471 Phone: +1 (510) 486-7518 472 Email: floyd@ee.lbl.gov 473 URL: http://www-nrg.ee.lbl.gov/floyd/ 475 This draft was created in November 1997. 476 It expires May 1998.