[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 RFC 2914

Internet Engineering Task Force            Sally Floyd, Editor
INTERNET DRAFT                                           ACIRI
draft-floyd-cong-00.txt                      October 1999
                                           Expires: April 2000

                     Congestion Control Principles

                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

1.  Introduction.

   The goal of this document is to explain the need for congestion
   control in the Internet, and to discuss what constitutes correct
   congestion control.  One specific goal is to illustrate the dangers
   of neglecting to apply proper congestion control.  A second goal is
   to discuss the role of the IETF in standardizing new congestion
   control protocols.

   This document draws heavily from earlier RFCs, in some cases
   reproducing entire sections of the text of earlier documents
   [RFC2309, RFC2357].  We have also borrowed heavily from earlier
   publications addressing the need for end-to-end congestion control
   [FF99].  NOTE:  This internet-draft is a rough first draft intended

Floyd                                                           [Page 1]

draft-ieft-floyd-cong-00                                    October 1999

   for further discussion in the IETF (written or gathered-together just
   before the deadline for submitting internet-drafts to the December
   IETF).

2.  Current standards on congestion control

   IETF standards concerning end-to-end congestion control focus either
   on specific protocols (e.g., TCP [RFC2581], reliable multicast
   protocols [RFC2357]) or on the syntax and semantics of communications
   between the end nodes and routers about congestion information (e.g.,
   Explicit Congestion Notification [RFC2481]) or desired quality-of-
   service (diff-serv)).  The role of end-to-end congestion control is
   also discussed in an Informational RFC on ``Recommendations on Queue
   Management and Congestion Avoidance in the Internet'' [RFC2309].  RFC
   2309 recommends the deployment of active queue management mechanisms
   in routers, and the continuation of design efforts towards mechanisms
   in routers to deal with flows that are unresponsive to congestion
   notification.  While this note does not address either of the two
   issues raised by RFC 2309, we freely borrow from RFC 2309 some of
   their general discussion of end-to-end congestion control.

   In contrast to the RFCs discussed above, this document is a more
   general discussion of the principles of congestion control.  One of
   the keys to the success of the Internet has been the congestion
   avoidance mechanisms of TCP.  While TCP is still the dominant
   transport protocol in the Internet, it is not ubiquitous, and there
   are an increasing number of applications that, for one reason or
   another, choose not to use TCP.  Such traffic includes not only
   multicast traffic, but unicast traffic such as streaming multimedia
   that does not require reliability; and traffic such as DNS or routing
   messages that consist of short transfers deemed critical to the
   operation of the network.  The continued use of end-to-end congestion
   control by best-effort traffic is critical for maintaining the
   stability of the Internet.

   This document also discusses the general role of the IETF in the
   standardization of new congestion control protocols.

   The discussion of congestion control principles for differentiated
   services or integrated services is a separate issue that is not
   addressed in this document.  Some categories of integrated or
   differentiated services include a guarantee by the network of end-to-
   end bandwidth, and as such do not require end-to-end congestion
   control mechanisms.

Floyd                                                           [Page 2]

draft-ieft-floyd-cong-00                                    October 1999

3.  The development of end-to-end congestion control.

3.1.  Preventing congestion collapse.

   The Internet protocol architecture is based on a connectionless end-
   to-end packet service using the IP protocol.  The advantages of its
   connectionless design, flexibility and robustness, have been amply
   demonstrated.  However, these advantages are not without cost:
   careful design is required to provide good service under heavy load.
   In fact, lack of attention to the dynamics of packet forwarding can
   result in severe service degradation or "Internet meltdown".  This
   phenomenon was first observed during the early growth phase of the
   Internet of the mid 1980s [RFC896], and is technically called
   "congestion collapse".

   The original specification of TCP [RFC793] included window-based flow
   control as a means for the receiver to govern the amount of data sent
   by the sender.  This flow control was used to prevent overflow of the
   receiver's data buffer space available for that connection.  [RFC793]
   reported that segments could be lost due either to errors or to
   network congestion, but did not include dynamic adjustment of the
   flow-control window in response to congestion.

   The original fix for Internet meltdown was provided by Van Jacobson.
   Beginning in 1986, Jacobson developed the congestion avoidance
   mechanisms that are now required in TCP implementations [Jacobson88,
   RFC 2581].  These mechanisms operate in the hosts to cause TCP
   connections to "back off" during congestion.  We say that TCP flows
   are "responsive" to congestion signals (i.e., dropped packets) from
   the network.  It is these TCP congestion avoidance algorithms that
   prevent the congestion collapse of today's Internet.

   However, that is not the end of the story.  Considerable research has
   been done on Internet dynamics since 1988, and the Internet has
   grown.  It has become clear that the TCP congestion avoidance
   mechanisms [RFC2581], while necessary and powerful, are not
   sufficient to provide good service in all circumstances.  In addition
   to the development of new congestion control mechanisms [RFC2357],
   router-based mechanisms are in development that complement the
   endpoint congestion avoidance mechanisms.

   A major issue that still needs to be addressed is the potential for
   future congestion collapse of the Internet due to flows that do not
   use responsible end-to-end congestion control.

Floyd                                                           [Page 3]

draft-ieft-floyd-cong-00                                    October 1999

3.2.  Fairness

   In addition to a concern about congestion collapse, there is a
   concern about ``fairness'' for best-effort traffic.  Because TCP
   "backs off" during congestion, a large number of TCP connections can
   share a single, congested link in such a way that bandwidth is shared
   reasonably equitably among similarly situated flows.  The equitable
   sharing of bandwidth among flows depends on the fact that all flows
   are running basically the same congestion avoidance algorithms,
   conformant with the current TCP specification [RFC793, RFC1122,
   RFC2581].

   The issue of fairness among competing TCP flows has become
   increasingly important for several reasons.  First, using window
   scaling [RFC1323], individual TCPs can use high bandwidth even over
   high-propagation-delay paths.  Second, with the growth of the web, ,
   Internet users increasing want high-bandwidth and low-delay
   communications (as opposed to the leisurely transfer of a long file
   in the background).  The growth of best-effort traffic that does not
   use TCP underscores this concern about fairness between competing
   best-effort traffic in times of congestion.

   The popularity of the Internet has caused a proliferation in the
   number of TCP implementations.  Some of these may fail to implement
   the TCP congestion avoidance mechanisms correctly because of poor
   implementation [RFC2525].  Others may deliberately be implemented
   with congestion avoidance algorithms that are more aggressive in
   their use of bandwidth than other TCP implementations; this would
   allow a vendor to claim to have a "faster TCP".  The logical
   consequence of such implementations would be a spiral of increasingly
   aggressive TCP implementations, leading back to the point where there
   is effectively no congestion avoidance and the Internet is
   chronically congested.

   There is a well-known way to achieve more aggressive TCP performance
   without even changing TCP, by changing the level of granularity: open
   multiple connections to the same place, as has been done in some Web
   browsers.  Thus, instead of a spiral of increasingly aggressive
   transport protocols, we could instead have a spiral of increasingly
   aggressive web browsers, or increasingly aggressive transport
   protocols.

   This raises the issue of the appropriate granularity of a "flow",
   where we define a ``flow'' as the level of granularity appropriate
   for the application of both fairness and congestion control..  From
   RFC 2309:  ``There are a few "natural" answers: 1) a TCP or UDP
   connection (source address/port, destination address/port); 2) a
   source/destination host pair; 3) a given source host or a given

Floyd                                                           [Page 4]

draft-ieft-floyd-cong-00                                    October 1999

   destination host.  We would guess that the source/destination host
   pair gives the most appropriate granularity in many circumstances.
   The granularity of flows for congestion management is, at least in
   part, a policy question that needs to be addressed in the wider IETF
   community.''

   Again borrowing from RFC 2309, we use the term "TCP-compatible" for a
   flow that behaves under congestion like a flow produced by a
   conformant TCP.  A TCP-compatible flow is responsive to congestion
   notification, and in steady-state it uses no more bandwidth than a
   conformant TCP running under comparable conditions (drop rate, RTT,
   MTU, etc.)

   It is convenient to divide flows into three classes: (1) TCP-
   compatible flows, (2) unresponsive flows, i.e., flows that do not
   slow down when congestion occurs, and (3) flows that are responsive
   but are not TCP-compatible.  The last two classes contain more
   aggressive flows that pose significant threats to Internet
   performance, as we discuss below.

3.3.  Optimizing performance regarding throughput, delay, and loss.

   In addition to the prevention of congestion collapse and concerns
   about fairness, a third reason for a flow to use end-to-end
   congestion control can be to optimize its own performance regarding
   throughput, delay, and loss.  In some circumstances, for example in
   environments of high statistical multiplexing, the delay and loss
   rate experienced by a flow might be largely independent of its own
   sending rate.  However, in environments with lower levels of
   statistical multiplexing or with per-flow scheduling, the delay and
   loss rate experienced by a flow can be in part a function of the
   flow's own sending rate.  Thus, a flow can use end-to-end congestion
   control to limit the delay or loss experienced by its own packets.
   We would note, however, that in an environment like the current best-
   effort Internet, concerns regarding congestion collapse and fairness
   with competing flows limit the range of congestion control behaviors
   available to a flow.

4.  The role of the standards process

   The standardization of a transport protocol includes not only
   standardization of aspects of the protocol that could affect
   interoperability (e.g., information exchanged by the end-nodes), but
   also standardization of mechanisms deemed critical to performance
   (e.g., in TCP, reduction of the congestion window in response to a
   packet drop).  At the same time, implementation-specific details and
   other aspects of the transport protocol that do not affect
   interoperability and do not significantly interfere with performance

Floyd                                                           [Page 5]

draft-ieft-floyd-cong-00                                    October 1999

   do not require standardization.  Areas of TCP that do not require
   standardization include the details of TCP's Fast Recovery procedure
   after a Fast Retransmit [RFC2582].  The appendix uses examples from
   TCP to discuss in more detail the role of the standards process in
   the development of congestion control.

   In addition to addressing the danger of congestion collapse, the
   standardization process for new transport protocols takes care to
   avoid a congestion control ``arms race'' among competing protocols.
   As an example, in RFC 2357 [RFC2357] the TSV Area Directors and their
   Directorate outline criteria for the publication as RFCs of Internet-
   Drafts on reliable multicast transport protocols.  From [RFC2357]:
   ``A particular concern for the IETF is the impact of reliable
   multicast traffic on other traffic in the Internet in times of
   congestion, in particular the effect of reliable multicast traffic on
   competing TCP traffic....  The challenge to the IETF is to encourage
   research and implementations of reliable multicast, and to enable the
   needs of applications for reliable multicast to be met as
   expeditiously as possible, while at the same time protecting the
   Internet from the congestion disaster or collapse that could result
   from the widespread use of applications with inappropriate reliable
   multicast mechanisms.''

   The list of technical criteria that must be addressed by RFCs on new
   reliable multicast transport protocols include the following:  ``Is
   there a congestion control mechanism? How well does it perform? When
   does it fail?  Note that congestion control mechanisms that operate
   on the network more aggressively than TCP will face a great burden of
   proof that they don't threaten network stability.''

   It is reasonable to expect that these concerns about the effect of
   new transport protocols on competing traffic will apply not only to
   reliable multicast protocols, but to unreliable unicast, reliable
   unicast, and unreliable multicast traffic as well.

5.  A description of congestion collapse

   This section discusses congestion collapse from undelivered packets
   in some detail, and shows how unresponsive flows could contribute to
   congestion collapse in the Internet.  This section draws heavily on
   material from [FF99].

   Informally, congestion collapse occurs when an increase in the
   network load results in a decrease in the useful work done by the
   network.  As discussed in Section 3, congestion collapse was first
   reported in the mid 1980s [RFC896], and was largely due to TCP
   connections unnecessarily retransmitting packets that were either in
   transit or had already been received at the receiver.  We call the

Floyd                                                           [Page 6]

draft-ieft-floyd-cong-00                                    October 1999

   congestion collapse that results from the unnecessary retransmission
   of packets classical congestion collapse.  Classical congestion
   collapse is a stable condition that can result in throughput that is
   a small fraction of normal [RFC896].  Problems with classical
   congestion collapse have generally been corrected by the timer
   improvements and congestion control mechanisms in modern
   implementations of TCP [Jacobson88].

   A second form of potential congestion collapse occurs due to
   undelivered packets.  Congestion collapse from undelivered packets
   arises when bandwidth is wasted by delivering packets through the
   network that are dropped before reaching their ultimate destination.
   This is probably the largest unresolved danger with respect to
   congestion collapse in the Internet today.  Different scenarios can
   result in different degrees of congestion collapse, in terms of the
   fraction of the congested links' bandwidth used for productive work.
   The danger of congestion collapse from undelivered packets is due
   primarily to the increasing deployment of open-loop applications not
   using end-to-end congestion control.  Even more destructive would be
   best-effort applications that *increase* their sending rate in
   response to an increased packet drop rate (e.g., automatically using
   an increased level of FEC).

   Table 1 gives the results from a scenario with congestion collapse
   from undelivered packets, where scarce bandwidth is wasted by packets
   that never reach their destination.  The simulation uses a scenario
   with three TCP flows and one UDP flow competing over a congested 1.5
   Mbps link.  The access links for all nodes are 10 Mbps, except that
   the access link to the receiver of the UDP flow is 128 Kbps, only 9
   of the bandwidth of shared link.  When the UDP source rate exceeds
   128 Kbps, most of the UDP packets will be dropped at the output port
   to that final link.

Floyd                                                           [Page 7]

draft-ieft-floyd-cong-00                                    October 1999

        UDP
        Arrival   UDP       TCP       Total
        Rate      Goodput   Goodput   Goodput
       --------------------------------------
         0.7       0.7      98.5      99.2
         1.8       1.7      97.3      99.1
         2.6       2.6      96.0      98.6
         5.3       5.2      92.7      97.9
         8.8       8.4      87.1      95.5
        10.5       8.4      84.8      93.2
        13.1       8.4      81.4      89.8
        17.5       8.4      77.3      85.7
        26.3       8.4      64.5      72.8
        52.6       8.4      38.1      46.4
        58.4       8.4      32.8      41.2
        65.7       8.4      28.5      36.8
        75.1       8.4      19.7      28.1
        87.6       8.4      11.3      19.7
       105.2       8.4       3.4      11.8
       131.5       8.4       2.4      10.7
   Table 1.  A simulation with three TCP flows and one UDP flow.

   Table 1 shows the UDP arrival rate from the sender, the UDP goodput
   (defined as the bandwidth delivered to the receiver), the TCP goodput
   (as delivered to the TCP receivers), and the aggregate goodput on the
   congested 1.5 Mbps link.  Each rate is given as a fraction of the
   bandwidth of the congested link.  As the UDP source rate increases,
   the TCP goodput decreases roughly linearly, and the UDP goodput is
   nearly constant.  Thus, as the UDP flow increases its offered load,
   its only effect is to hurt the TCP and aggregate goodput.  On the
   congested link, the UDP flow ultimately ``wastes'' the bandwidth that
   could have been used by the TCP flow, and reduces the goodput in the
   network as a whole down to a small fraction of the bandwidth of the
   congested link.

   The simulations in Table 1 illustrate both unfairness and congestion
   collapse.  As [FF99] discusses, compatible congestion control is not
   the only way to provide fairness; per-flow scheduling at the
   congested routers is an alternative mechanism at the routers that
   guarantees fairness.  However, as discussed in [FF99], per-flow
   scheduling can not be relied upon to prevent congestion collapse.

   There are only two alternatives for eliminating the danger of
   congestion collapse from undelivered packets.  The first alternative
   for preventing congestion collapse from undelivered packets is the
   use of effective end-to-end congestion control by the end nodes.
   More specifically, the requirement would be that a flow avoid a
   pattern of significant losses at links downstream from the first

Floyd                                                           [Page 8]

draft-ieft-floyd-cong-00                                    October 1999

   congested link on the path.  (Here, we would consider any link a
   ``congested link'' if any flow is using bandwidth that would
   otherwise be used by other traffic on the link.) Given that an end-
   node is generally unable to distinguish between a path with one
   congested link and a path with multiple congested links, the most
   reliable way for a flow to avoid a pattern of significant losses at a
   downstream congested link is for the flow to use end-to-end
   congestion control, and reduce its sending rate in the presence of
   loss.

   A second alternative for preventing congestion collapse from
   undelivered packets would be a guarantee by the network that packets
   accepted at a congested link in the network will be delivered all the
   way to the receiver.  We note that the choice between the first
   alternative of end-to-end congestion control and the second
   alternative of end-to-end bandwidth guarantees does not have to be an
   either/or decision; congestion collapse can be prevented by the use
   of effective end-to-end congestion by some of the traffic, and the
   use of end-to-end bandwidth guarantees from the network for the rest
   of the traffic.

6.  Forms of end-to-end congestion control

   This document has discussed extensively concerns about congestion
   collapse and about fairness of new forms of congestion control with
   TCP.  This does not mean, however, that concerns about congestion
   collapse and fairness with TCP necessitate that all best-effort
   traffic deploy congestion control based on TCP's Additive-Increase
   Multiplicative-Decrease (AIMD) algorithm of reducing the sending rate
   in half in response to each packet drop.  This section separately
   discusses the implications of these two concerns of congestion
   collapse and fairness with TCP.

6.1.  End-to-end congestion control for avoiding congestion collapse.

   The avoidance of congestion collapse from undelivered packets
   requires that flows avoid a scenario of a high sending rate, multiple
   congested links, and a persistent high packet drop rate at the
   downstream link.  Because congestion collapse from undelivered
   packets consists of packets that waste valuable bandwidth only to be
   dropped downstream, this form of congestion collapse is not possible
   in an environment where each flow traverses only one congested link,
   or where only a small number of packets are dropped at links
   downstream of the first congested link.  Thus, any form of congestion
   control that successfully avoids a high sending rate in the presence
   of a high packet drop rate should be sufficient to avoid congestion
   collapse from undelivered packets.

Floyd                                                           [Page 9]

draft-ieft-floyd-cong-00                                    October 1999

   We would note that the addition of Explicit Congestion Notification
   (ECN) to the IP architecture would not, in and of itself, remove the
   danger of congestion collapse for best-effort traffic.  ECN is an
   experimental proposal that would allow routers to set a bit in packet
   headers as an indication of congestion to the end-nodes, rather than
   being forced to rely on packet drops to indicate congestion.
   However, with ECN, packet-marking would replace packet-dropping only
   in times of moderate congestion.  In particular, when congestion is
   heavy, and a router's buffers overflow, the router has no choice but
   to drop arriving packets.

6.2.  End-to-end congestion control for fairness with TCP.

   The concern expressed in [RFC2357] about fairness with TCP places a
   significant though not crippling constraint on the range of viable
   end-to-end congestion control mechanisms for best-effort traffic.  An
   environment with per-flow scheduling at all congested links would
   isolate flows from each other, and eliminate the need for congestion
   control mechanisms to be TCP-compatible.  An environment with
   differentiated services and some form of class-based scheduling,
   where flows marked as belonging to a certain diff-serv class would be
   scheduled in isolation from best-effort traffic, could allow the
   emergence of an entire diff-serv class of traffic where congestion
   control was not required to be TCP-compatible.  Similarly, a pricing-
   controlled environment, or a diff-serv class with its own pricing
   paradigm, could supercede the concern about fairness with TCP.
   However, for the current Internet environment, where other best-
   effort traffic could compete in a FIFO queue with TCP traffic, the
   absence of fairness with TCP could lead to one flow ``starving out''
   another flow in a time of high congestion, as was illustrated in
   Table 1 above.

   However, the list of TCP-compatible congestion control procedures is
   not limited to AIMD with the same increase/ decrease parameters as
   TCP.  Other TCP-compatible congestion control procedures include
   rate-based variants of AIMD; AIMD with different sets of
   increase/decrease parameters;  equation-based congestion control
   where the sender adjusts its sending rate in response to information
   about the long-term packet drop rate; layered multicast where
   receivers subscribe and unsubscribe from layered multicast groups;
   and possibly other forms that we have not yet begun to consider.

Floyd                                                          [Page 10]

draft-ieft-floyd-cong-00                                    October 1999

7. Acknowledgements

   Much of this document draws directly on previous RFCs addressing end-
   to-end congestion control.  This attempts to be a summary of ideas
   that have been discussed for many years, and by many people.  In
   particular, acknowledgement is due to the members of the End-to-End
   Research Group, the Reliable Multicast Research Group, and the
   Transport Area Directorate.

Floyd                                                          [Page 11]

draft-ieft-floyd-cong-00                                    October 1999

8. References

   [FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End
   Congestion Control in the Internet. IEEE/ACM Transactions on
   Networking, August 1999.  URL http://www-
   nrg.ee.lbl.gov/floyd/end2end-paper.html".

   [Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM
   SIGCOMM '88, August 1988.

   [RFC793] J. Postel, Transmission Control Protocol," RFC 793,
   September 1981.

   [RFC896] Nagle, J., Congestion Control in IP/TCP", RFC 896, January
   1984.

   [RFC1122] Braden, R., Ed., Requirements for Internet Hosts --
   Communication Layers, STD 3, RFC 1122, October 1989.

   [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
   Requirement Levels, RFC 2119, March 1997.

   [RFC2309] B. Braden, Clark, D., Crowcroft, J., Davie, B., S. Deering,
   Estrin, D., Floyd, S., V. Jacobson, G. Minshall, Partridge, C., L.
   Peterson, Ramakrishnan, K.K., Shenker, S., Wroclawski, J., and Zhang,
   L., Recommendations on Queue Management and Congestion Avoidance in
   the Internet, RFC 2309, April 1998.

   [RFC2357] A. Mankin, A. Romanow, S. Bradner, and V. Paxson, IETF
   Criteria for Evaluating Reliable Multicast Transport and Application
   Protocols, RFC 2357, June 1998.

   [RFC2414] Allman, M., Floyd, S., and Partridge, C., Increasing TCP's
   Initial Window, RFC 2414, Experimental, September 1998.

   [RFC2481] K. Ramakrishnan and S. Floyd, A Proposal to add Explicit
   Congestion Notification (ECN) to IP, RFC 2481, January 1999.

   [RFC2525] V. Paxson, M Allman, S. Dawson, W. Fenner, and J. Griner,
   I. Heavens, K. Lahey, J. Semke, B. Volz, Known TCP Implementation
   Problems, RFC 2525, March 1999.

   [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
   Control, RFC 2581, April 1999.

   [RFC2582] Floyd, S., and Henderson, T., The NewReno Modification to
   TCP's Fast Recovery Algorithm, RFC 2582, April 1999.

Floyd                                                          [Page 12]

draft-ieft-floyd-cong-00                                    October 1999

9.  TCP-Specific issues

   In this section we discuss some of the particulars of TCP congestion
   control, to illustrate a realization of the congestion control
   principles, including some of the details that arise when
   incorporating them into a production transport protocol.

   [We re-emphasize that is a rough draft of a document to be discussed
   in the IETF.  This is not necessarily a reflection of a rough
   consensus in the IETF.]

9.1.  Slow-start.

   The TCP sender can not open a new connection by sending a large burst
   of data (e.g., a receiver's advertised window) all at once.  The TCP
   sender is limited by a small initial value for the congestion window.
   During slow-start, the TCP sender can increase its sending rate by at
   most a factor of two in one roundtrip time.  Slow-start ends when the
   sender's congestion window is greater than the slow-start threshold
   ssthresh.

   An issue that potentially affects global congestion control, and
   therefore has been explicitly addressed in the standards process,
   includes an increase in the value of the initial window
   [RFC2414,RFC2581].

   Issues that have not been addressed in the standards process, and are
   generally considered not to require standardization, include such
   issues as the use (or non-use) of rate-based pacing, and mechanisms
   for ending slow-start early, before the congestion window reaches
   ssthresh.

9.2.  Additive Increase, Multiplicative Decrease.

   In the absence of congestion, the TCP sender increases its congestion
   window by at most one packet per roundtrip time (or more precisely,
   by at most 1/W packets for each ACK received).  In response to a
   packet drop, the TCP sender decreases its congestion window by half.
   (More precisely, the new congestion window is half of the minimum of
   the congestion window and the receiver's advertised window.)

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, would include a proposed addition of congestion control for
   the return stream of ``pure acks''.  A similar issue would be a
   proposal for increasing TCP's congestion window based on the number
   of bytes acked, rather than on the number of acknowledgements
   received;

Floyd                                                          [Page 13]

draft-ieft-floyd-cong-00                                    October 1999

   An issue that has not been addressed in the standards process, and is
   generally not considered to require standardization, would be a
   change to the congestion window to apply as an upper bound on the
   number of bytes presumed to be in the pipe, instead of applying as a
   sliding window starting from the cumulative acknowledgement.
   (Clearly, the receiver's advertised window applies as a sliding
   window starting from the cumulative acknowledgement field, because
   packets received above the cumulative acknowledgement field are held
   in TCP's receive buffer, and have not been delivered to the
   application.  However, the congestion window applies to the number of
   packets outstanding in the pipe, and does not necessarily have to
   include packets that have been received out-of-order by the TCP
   receiver.)

9.3.  Retransmit timers.

   The TCP sender sets a retransmit timer to infer that a packet has
   been dropped in the network.  When the retransmit timer expires, the
   sender infers that a packet has been lost, sets ssthresh to half of
   the current window, and goes into slow-start, retransmitting the lost
   packet.  If the retransmit timer expires because no acknowledgement
   has been received for a retransmitted packet, the retransmit timer is
   also "backed-off", doubling the value of the next retransmit timeout
   interval.

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, might include a modified mechanism for setting the
   retransmit timer that could significantly increase the number of
   retransmit timers that expire prematurely, when the acknowledgement
   has not yet arrived at the sender, but in fact no packets have been
   dropped.  This could be of concern to the Internet standards process
   because retransmit timers that expire prematurely could lead to an
   increase in the number of packets unnecessarily transmitted on a
   congested link.

   An issue that has not been addressed in the standards process, and
   would be less likely to require standardization, would be a proposed
   change to algorithms for setting the retransmit timer that would not
   be expected to significantly increase the chance of the retransmit
   timer expiring prematurely.

9.4.  Fast Retransmit and Fast Recovery.

   After seeing three duplicate acknowledgements, the TCP sender infers
   a packet loss.  The TCP sender sets ssthresh to half of the current
   window, reduces the congestion window to at most half of the previous
   window, and retransmits the lost packet.

Floyd                                                          [Page 14]

draft-ieft-floyd-cong-00                                    October 1999

   An issue that potentially affects global congestion control, and
   therefore would be likely to be explicitly addressed in the standards
   process, might include a proposal (if there was one) for inferring a
   lost packet after only one or two duplicate acknowledgements.  If
   poorly designed, such a proposal could lead to an increase in the
   number of packets unnecessarily transmitted on a congested path.

   An issue that has not been addressed in the standards process, and
   would not be expected to require standardization, would be a proposal
   to send a "new" or presumed-lost packet in response to a duplicate or
   partial acknowledgement, if allowed by the congestion window.  An
   example of this would be sending a new packet in response to a single
   duplicate acknowledgement, to keep the ``ack clock'' going in case no
   further acknowledgements would have arrived.

9.5.  Other aspects of TCP congestion control.

   Other aspects of TCP congestion control that have not been discussed
   in any of the sections above include TCP's recovery from an idle or
   application-limited period, as well as the entire set of issues
   raised by the proposal for Explicit Congestion Management.

10. Security Considerations

AUTHORS' ADDRESSES

   Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)
   Phone: +1 (510) 642-4274 x189
   Email: floyd@aciri.org
   URL: http://www.aciri.org/floyd/

   This draft was created in October 1999.
   It expires April 2000.

Floyd                                                          [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/