As per Relevance of the word congestion, we have this rfc below:
Network Working Group S.
Request for Comments: 2914
BCP: 41 September 2000
Category: Best Current
Congestion Control
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The goal of this document is to explain the need for
control in the Internet, and to discuss what constitutes
congestion control. One specific goal is to illustrate the
of neglecting to apply proper congestion control. A second goal
to discuss the role of the IETF in standardizing new
control protocols
1.
This document draws heavily from earlier RFCs, in some
reproducing entire sections of the text of earlier
[RFC2309, RFC2357]. We have also borrowed heavily from
publications addressing the need for end-to-end congestion
[FF99].
2. Current standards on congestion
IETF standards concerning end-to-end congestion control focus
on specific protocols (e.g., TCP [RFC2581], reliable
protocols [RFC2357]) or on the syntax and semantics of
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
also discussed in an Informational RFC on "Recommendations on
Management and Congestion Avoidance in the Internet" [RFC2309].
2309 recommends the deployment of active queue management
in routers, and the continuation of design efforts towards
Floyd, ed. Best Current Practice [Page 1]
RFC 2914 Congestion Control Principles September 2000
in routers to deal with flows that are unresponsive to
notification. We freely borrow from RFC 2309 some of their
discussion of end-to-end congestion control
In contrast to the RFCs discussed above, this document is a
general discussion of the principles of congestion control. One
the keys to the success of the Internet has been the
avoidance mechanisms of TCP. While TCP is still the
transport protocol in the Internet, it is not ubiquitous, and
are an increasing number of applications that, for one reason
another, choose not to use TCP. Such traffic includes not
multicast traffic, but unicast traffic such as streaming
that does not require reliability; and traffic such as DNS or
messages that consist of short transfers deemed critical to
operation of the network. Much of this traffic does not use any
of either bandwidth reservations or end-to-end congestion control
The continued use of end-to-end congestion control by best-
traffic is critical for maintaining the stability of the Internet
This document also discusses the general role of the IETF in
standardization of new congestion control protocols
The discussion of congestion control principles for
services or integrated services is not addressed in this document
Some categories of integrated or differentiated services include
guarantee by the network of end-to-end bandwidth, and as such do
require end-to-end congestion control mechanisms
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
connectionless design, flexibility and robustness, have been
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
result in severe service degradation or "Internet meltdown".
phenomenon was first observed during the early growth phase of
Internet of the mid 1980s [RFC896], and is technically
"congestion collapse".
The original specification of TCP [RFC793] included window-based
control as a means for the receiver to govern the amount of data
by the sender. This flow control was used to prevent overflow of
receiver's data buffer space available for that connection. [RFC793]
Floyd, ed. Best Current Practice [Page 2]
RFC 2914 Congestion Control Principles September 2000
reported that segments could be lost due either to errors or
network congestion, but did not include dynamic adjustment of
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
mechanisms that are now required in TCP implementations [Jacobson88,
RFC 2581]. These mechanisms operate in the hosts to cause
connections to "back off" during congestion. We say that TCP
are "responsive" to congestion signals (i.e., dropped packets)
the network. It is these TCP congestion avoidance algorithms
prevent the congestion collapse of today's Internet
However, that is not the end of the story. Considerable research
been done on Internet dynamics since 1988, and the Internet
grown. It has become clear that the TCP congestion
mechanisms [RFC2581], while necessary and powerful, are
sufficient to provide good service in all circumstances. In
to the development of new congestion control mechanisms [RFC2357],
router-based mechanisms are in development that complement
endpoint congestion avoidance mechanisms
A major issue that still needs to be addressed is the potential
future congestion collapse of the Internet due to flows that do
use responsible end-to-end congestion control. RFC 896 [RFC896]
suggested in 1984 that gateways should detect and `squelch
misbehaving hosts: "Failure to respond to an ICMP Source
message, though, should be regarded as grounds for action by
gateway to disconnect a host. Detecting such failure is non-
but is a worthwhile area for further research." Current
still propose that routers detect and penalize flows that are
employing acceptable end-to-end congestion control [FF99].
3.2.
In addition to a concern about congestion collapse, there is
concern about `fairness' for best-effort traffic. Because TCP "
off" during congestion, a large number of TCP connections can share
single, congested link in such a way that bandwidth is
reasonably equitably among similarly situated flows. The
sharing of bandwidth among flows depends on the fact that all
are running compatible congestion control algorithms. For TCP,
means congestion control algorithms conformant with the current
specification [RFC793, RFC1122, RFC2581].
The issue of fairness among competing flows has become
important for several reasons. First, using window
[RFC1323], individual TCPs can use high bandwidth even over high
Floyd, ed. Best Current Practice [Page 3]
RFC 2914 Congestion Control Principles September 2000
propagation-delay paths. Second, with the growth of the web
Internet users increasingly want high-bandwidth and low-
communications, rather than the leisurely transfer of a long file
the background. The growth of best-effort traffic that does not
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
number of TCP implementations. Some of these may fail to
the TCP congestion avoidance mechanisms correctly because of
implementation [RFC2525]. Others may deliberately be
with congestion avoidance algorithms that are more aggressive
their use of bandwidth than other TCP implementations; this
allow a vendor to claim to have a "faster TCP". The
consequence of such implementations would be a spiral of
aggressive TCP implementations, or increasingly aggressive
protocols, leading back to the point where there is effectively
congestion avoidance and the Internet is chronically congested
There is a well-known way to achieve more aggressive
without even changing the transport protocol, by changing the
of granularity: open multiple connections to the same place, as
been done in the past by some Web browsers. Thus, instead of
spiral of increasingly aggressive transport protocols, we
instead have a spiral of increasingly aggressive web browsers,
increasingly aggressive applications
This raises the issue of the appropriate granularity of a "flow",
where we define a `flow' as the level of granularity appropriate
the application of both fairness and congestion control. From
2309: "There are a few `natural' answers: 1) a TCP or UDP
(source address/port, destination address/port); 2)
source/destination host pair; 3) a given source host or a
destination host. We would guess that the source/destination
pair gives the most appropriate granularity in many circumstances
The granularity of flows for congestion management is, at least
part, a policy question that needs to be addressed in the wider
community."
Again borrowing from RFC 2309, we use the term "TCP-compatible" for
flow that behaves under congestion like a flow produced by
conformant TCP. A TCP-compatible flow is responsive to
notification, and in steady-state uses no more bandwidth than
conformant TCP running under comparable conditions (drop rate, RTT
MTU, etc.)
Floyd, ed. Best Current Practice [Page 4]
RFC 2914 Congestion Control Principles September 2000
It is convenient to divide flows into three classes: (1) TCP
compatible flows, (2) unresponsive flows, i.e., flows that do
slow down when congestion occurs, and (3) flows that are
but are not TCP-compatible. The last two classes contain
aggressive flows that pose significant threats to
performance, as we discuss below
In addition to steady-state fairness, the fairness of the
slow-start is also a concern. One concern is the transient effect
other flows of a flow with an overly-aggressive slow-start procedure
Slow-start performance is particularly important for the many
that are short-lived, and only have a small amount of data
transfer
3.3. Optimizing performance regarding throughput, delay, and loss
In addition to the prevention of congestion collapse and
about fairness, a third reason for a flow to use end-to-
congestion control can be to optimize its own performance
throughput, delay, and loss. In some circumstances, for example
environments of high statistical multiplexing, the delay and
rate experienced by a flow are largely independent of its own
rate. However, in environments with lower levels of
multiplexing or with per-flow scheduling, the delay and loss
experienced by a flow is in part a function of the flow's own
rate. Thus, a flow can use end-to-end congestion control to
the delay or loss experienced by its own packets. We would note
however, that in an environment like the current best-
Internet, concerns regarding congestion collapse and fairness
competing flows limit the range of congestion control
available to a flow
4. The role of the standards
The standardization of a transport protocol includes not
standardization of aspects of the protocol that could
interoperability (e.g., information exchanged by the end-nodes),
also standardization of mechanisms deemed critical to
(e.g., in TCP, reduction of the congestion window in response to
packet drop). At the same time, implementation-specific details
other aspects of the transport protocol that do not
interoperability and do not significantly interfere with
do not require standardization. Areas of TCP that do not
standardization include the details of TCP's Fast Recovery
after a Fast Retransmit [RFC2582]. The appendix uses examples
TCP to discuss in more detail the role of the standards process
the development of congestion control
Floyd, ed. Best Current Practice [Page 5]
RFC 2914 Congestion Control Principles September 2000
4.1. The development of new transport protocols
In addition to addressing the danger of congestion collapse,
standardization process for new transport protocols takes care
avoid a congestion control `arms race' among competing protocols.
an example, in RFC 2357 [RFC2357] the TSV Area Directors and
Directorate outline criteria for the publication as RFCs
Internet-Drafts on reliable multicast transport protocols.
[RFC2357]: "A particular concern for the IETF is the impact
reliable multicast traffic on other traffic in the Internet in
of congestion, in particular the effect of reliable multicast
on competing TCP traffic.... The challenge to the IETF is
encourage research and implementations of reliable multicast, and
enable the needs of applications for reliable multicast to be met
expeditiously as possible, while at the same time protecting
Internet from the congestion disaster or collapse that could
from the widespread use of applications with inappropriate
multicast mechanisms."
The list of technical criteria that must be addressed by RFCs on
reliable multicast transport protocols include the following: "
there a congestion control mechanism? How well does it perform?
does it fail? Note that congestion control mechanisms that
on the network more aggressively than TCP will face a great burden
proof that they don't threaten network stability."
It is reasonable to expect that these concerns about the effect
new transport protocols on competing traffic will apply not only
reliable multicast protocols, but to unreliable unicast,
unicast, and unreliable multicast traffic as well
4.2. Application-level issues that affect congestion
The specific issue of a browser opening multiple connections to
same destination has been addressed by RFC 2616 [RFC2616],
states in Section 8.1.4 that "Clients that use persistent
SHOULD limit the number of simultaneous connections that
maintain to a given server. A single-user client SHOULD NOT
more than 2 connections with any server or proxy."
4.3. New developments in the standards
The most obvious developments in the IETF that could affect
evolution of congestion control are the development of integrated
differentiated services [RFC2212, RFC2475] and of Explicit
Notification (ECN) [RFC2481]. However, other less
developments are likely to affect congestion control as well
Floyd, ed. Best Current Practice [Page 6]
RFC 2914 Congestion Control Principles September 2000
One such effort is that to construct Endpoint Congestion
[BS00], to enable multiple concurrent flows from a sender to the
receiver to share congestion control state. By allowing
connections to the same destination to act as one flow in terms
end-to-end congestion control, a Congestion Manager could
individual connections slow-starting to take advantage of
information about the congestion state of the end-to-end path
Further, the use of a Congestion Manager could remove the
control dangers of multiple flows being opened between the
source/destination pair, and could perhaps be used to allow a
to open many simultaneous connections to the same destination
5. A description of congestion
This section discusses congestion collapse from undelivered
in some detail, and shows how unresponsive flows could contribute
congestion collapse in the Internet. This section draws heavily
material from [FF99].
Informally, congestion collapse occurs when an increase in
network load results in a decrease in the useful work done by
network. As discussed in Section 3, congestion collapse was
reported in the mid 1980s [RFC896], and was largely due to
connections unnecessarily retransmitting packets that were either
transit or had already been received at the receiver. We call
congestion collapse that results from the unnecessary
of packets classical congestion collapse. Classical
collapse is a stable condition that can result in throughput that
a small fraction of normal [RFC896]. Problems with
congestion collapse have generally been corrected by the
improvements and congestion control mechanisms in
implementations of TCP [Jacobson88].
A second form of potential congestion collapse occurs due
undelivered packets. Congestion collapse from undelivered
arises when bandwidth is wasted by delivering packets through
network that are dropped before reaching their ultimate destination
This is probably the largest unresolved danger with respect
congestion collapse in the Internet today. Different scenarios
result in different degrees of congestion collapse, in terms of
fraction of the congested links' bandwidth used for productive work
The danger of congestion collapse from undelivered packets is
primarily to the increasing deployment of open-loop applications
using end-to-end congestion control. Even more destructive would
best-effort applications that *increase* their sending rate
response to an increased packet drop rate (e.g., automatically
an increased level of FEC).
Floyd, ed. Best Current Practice [Page 7]
RFC 2914 Congestion Control Principles September 2000
Table 1 gives the results from a scenario with congestion
from undelivered packets, where scarce bandwidth is wasted by
that never reach their destination. The simulation uses a
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
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
128 Kbps, most of the UDP packets will be dropped at the output
to that final link
Arrival UDP TCP
Rate 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
(defined as the bandwidth delivered to the receiver), the TCP
(as delivered to the TCP receivers), and the aggregate goodput on
congested 1.5 Mbps link. Each rate is given as a fraction of
bandwidth of the congested link. As the UDP source rate increases
the TCP goodput decreases roughly linearly, and the UDP goodput
nearly constant. Thus, as the UDP flow increases its offered load
its only effect is to hurt the TCP and aggregate goodput. On
congested link, the UDP flow ultimately `wastes' the bandwidth
could have been used by the TCP flow, and reduces the goodput in
network as a whole down to a small fraction of the bandwidth of
congested link
Floyd, ed. Best Current Practice [Page 8]
RFC 2914 Congestion Control Principles September 2000
The simulations in Table 1 illustrate both unfairness and
collapse. As [FF99] discusses, compatible congestion control is
the only way to provide fairness; per-flow scheduling at
congested routers is an alternative mechanism at the routers
guarantees fairness. However, as discussed in [FF99], per-
scheduling can not be relied upon to prevent congestion collapse
There are only two alternatives for eliminating the danger
congestion collapse from undelivered packets. The first
for preventing congestion collapse from undelivered packets is
use of effective end-to-end congestion control by the end nodes
More specifically, the requirement would be that a flow avoid
pattern of significant losses at links downstream from the
congested link on the path. (Here, we would consider any link
`congested link' if any flow is using bandwidth that would
be used by other traffic on the link.) Given that an end-node
generally unable to distinguish between a path with one
link and a path with multiple congested links, the most reliable
for a flow to avoid a pattern of significant losses at a
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
undelivered packets would be a guarantee by the network that
accepted at a congested link in the network will be delivered all
way to the receiver [RFC2212, RFC2475]. We note that the
between the first alternative of end-to-end congestion control
the second alternative of end-to-end bandwidth guarantees does
have to be an either/or decision; congestion collapse can
prevented by the use of effective end-to-end congestion by some
the traffic, and the use of end-to-end bandwidth guarantees from
network for the rest of the traffic
6. Forms of end-to-end congestion
This document has discussed concerns about congestion collapse
about fairness with TCP for new forms of congestion control.
does not mean, however, that concerns about congestion collapse
fairness with TCP necessitate that all best-effort traffic
congestion control based on TCP's Additive-Increase Multiplicative
Decrease (AIMD) algorithm of reducing the sending rate in half
response to each packet drop. This section separately discusses
implications of these two concerns of congestion collapse
fairness with TCP
Floyd, ed. Best Current Practice [Page 9]
RFC 2914 Congestion Control Principles September 2000
6.1. End-to-end congestion control for avoiding congestion collapse
The avoidance of congestion collapse from undelivered
requires that flows avoid a scenario of a high sending rate,
congested links, and a persistent high packet drop rate at
downstream link. Because congestion collapse from
packets consists of packets that waste valuable bandwidth only to
dropped downstream, this form of congestion collapse is not
in an environment where each flow traverses only one congested link
or where only a small number of packets are dropped at
downstream of the first congested link. Thus, any form of
control that successfully avoids a high sending rate in the
of a high packet drop rate should be sufficient to avoid
collapse from undelivered packets
We would note that the addition of Explicit Congestion
(ECN) to the IP architecture would not, in and of itself, remove
danger of congestion collapse for best-effort traffic. ECN
routers to set a bit in packet headers as an indication of
to the end-nodes, rather than being forced to rely on packet drops
indicate congestion. However, with ECN, packet-marking would
packet-dropping only in times of moderate congestion. In particular
when congestion is heavy, and a router's buffers overflow, the
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
significant though not crippling constraint on the range of
end-to-end congestion control mechanisms for best-effort traffic.
environment with per-flow scheduling at all congested links
isolate flows from each other, and eliminate the need for
control mechanisms to be TCP-compatible. An environment
differentiated services, where flows marked as belonging to a
diff-serv class would be scheduled in isolation from best-
traffic, could allow the emergence of an entire diff-serv class
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
about fairness with TCP. However, for the current
environment, where other best-effort traffic could compete in a
queue with TCP traffic, the absence of fairness with TCP could
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
not limited to AIMD with the same increase/ decrease parameters
TCP. Other TCP-compatible congestion control procedures
Floyd, ed. Best Current Practice [Page 10]
RFC 2914 Congestion Control Principles September 2000
rate-based variants of AIMD; AIMD with different sets
increase/decrease parameters that give the same steady-
behavior; equation-based congestion control where the sender
its sending rate in response to information about the long-
packet drop rate; layered multicast where receivers subscribe
unsubscribe from layered multicast groups; and possibly other
that we have not yet begun to consider
7.
Much of this document draws directly on previous RFCs
end-to-end congestion control. This attempts to be a summary
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
Transport Area Directorate. This document has also benefited
discussion and feedback from the Transport Area Working Group
Particular thanks are due to Mark Allman for feedback on an
version of this document
8.
[BS00] Balakrishnan H. and S. Seshan, "The Congestion Manager",
Work in Progress
[DMKM00] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret
"End-to-end Performance Implications of Slow Links",
Work in Progress
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-
Congestion Control in the Internet", IEEE/
Transactions on Networking, August 1999.
http://www.aciri.org/floyd/end2end-paper.
[HPF00] Handley, M., Padhye, J. and S. Floyd, "TCP
Window Validation", RFC 2861, June 2000.
[Jacobson88] V. Jacobson, Congestion Avoidance and Control,
SIGCOMM '88, August 1988.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
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.
Floyd, ed. Best Current Practice [Page 11]
RFC 2914 Congestion Control Principles September 2000
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP
for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "
of Guaranteed Quality of Service", RFC 2212,
1997.
[RFC2309] Braden, R., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L., Ramakrishnan
K.K., Shenker, S., Wroclawski, J., and L. Zhang
"Recommendations on Queue Management and
Avoidance in the Internet", RFC 2309, April 1998.
[RFC2357] Mankin, A., Romanow, A., Bradner, S. and V. Paxson
"IETF Criteria for Evaluating Reliable
Transport and Application Protocols", RFC 2357,
1998.
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "
TCP's Initial Window", RFC 2414, September 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to
Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner
J., Heavens, I., Lahey, K., Semke, J. and B. Volz
"Known TCP Implementation Problems", RFC 2525,
1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP
Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Floyd, ed. Best Current Practice [Page 12]
RFC 2914 Congestion Control Principles September 2000
[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson
TCP Congestion Control with a Misbehaving Receiver,
Computer Communications Review, October 1999.
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan,
Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of
Busy Internet Server: Analysis and Improvements,
Infocom, March 1998. Available from
"http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".
[TCPF98] Dong Lin and H.T. Kung, TCP Fast Recovery Strategies
Analysis and Improvements, IEEE Infocom, March 1998.
Available from
"http://www.eecs.harvard.edu/networking/papers/infocom
tcp-final-198.pdf".
9. TCP-Specific
In this section we discuss some of the particulars of TCP
control, to illustrate a realization of the congestion
principles, including some of the details that arise
incorporating them into a production transport protocol
9.1. Slow-start
The TCP sender can not open a new connection by sending a large
of data (e.g., a receiver's advertised window) all at once. The
sender is limited by a small initial value for the congestion window
During slow-start, the TCP sender can increase its sending rate by
most a factor of two in one roundtrip time. Slow-start ends
congestion is detected, or when the sender's congestion window
greater than the slow-start threshold ssthresh
An issue that potentially affects global congestion control,
therefore has been explicitly addressed in the standards process
includes an increase in the value of the initial
[RFC2414,RFC2581].
Issues that have not been addressed in the standards process, and
generally considered not to require standardization, include
issues as the use (or non-use) of rate-based pacing, and
for ending slow-start early, before the congestion window
ssthresh. Such mechanisms result in slow-start behavior that is
conservative or more conservative than standard TCP
Floyd, ed. Best Current Practice [Page 13]
RFC 2914 Congestion Control Principles September 2000
9.2. Additive Increase, Multiplicative Decrease
In the absence of congestion, the TCP sender increases its
window by at most one packet per roundtrip time. In response to
congestion indication, the TCP sender decreases its congestion
by half. (More precisely, the new congestion window is half of
minimum of the congestion window and the receiver's
window.)
An issue that potentially affects global congestion control,
therefore would be likely to be explicitly addressed in the
process, would include a proposed addition of congestion control
the return stream of `pure acks'.
An issue that has not been addressed in the standards process, and
generally not considered to require standardization, would be
change to the congestion window to apply as an upper bound on
number of bytes presumed to be in the pipe, instead of applying as
sliding window starting from the cumulative acknowledgement
(Clearly, the receiver's advertised window applies as a
window starting from the cumulative acknowledgement field,
packets received above the cumulative acknowledgement field are
in TCP's receive buffer, and have not been delivered to
application. However, the congestion window applies to the number
packets outstanding in the pipe, and does not necessarily have
include packets that have been received out-of-order by the
receiver.)
9.3. Retransmit timers
The TCP sender sets a retransmit timer to infer that a packet
been dropped in the network. When the retransmit timer expires,
sender infers that a packet has been lost, sets ssthresh to half
the current window, and goes into slow-start, retransmitting the
packet. If the retransmit timer expires because no
has been received for a retransmitted packet, the retransmit timer
also "backed-off", doubling the value of the next retransmit
interval
An issue that potentially affects global congestion control,
therefore would be likely to be explicitly addressed in the
process, might include a modified mechanism for setting
retransmit timer that could significantly increase the number
retransmit timers that expire prematurely, when the
has not yet arrived at the sender, but in fact no packets have
dropped. This could be of concern to the Internet standards
Floyd, ed. Best Current Practice [Page 14]
RFC 2914 Congestion Control Principles September 2000
because retransmit timers that expire prematurely could lead to
increase in the number of packets unnecessarily transmitted on
congested link
9.4. Fast Retransmit and Fast Recovery
After seeing three duplicate acknowledgements, the TCP sender
a packet loss. The TCP sender sets ssthresh to half of the
window, reduces the congestion window to at most half of the
window, and retransmits the lost packet
An issue that potentially affects global congestion control,
therefore would be likely to be explicitly addressed in the
process, might include a proposal (if there was one) for inferring
lost packet after only one or two duplicate acknowledgements.
poorly designed, such a proposal could lead to an increase in
number of packets unnecessarily transmitted on a congested path
An issue that has not been addressed in the standards process,
would not be expected to require standardization, would be a
to send a "new" or presumed-lost packet in response to a duplicate
partial acknowledgement, if allowed by the congestion window.
example of this would be sending a new packet in response to a
duplicate acknowledgement, to keep the `ack clock' going in case
further acknowledgements would have arrived. Such a proposal is
example of a beneficial change that does not involve
and does not affect global congestion control, and that
could be implemented by vendors without requiring the intervention
the IETF standards process. (This issue has in fact been
in [DMKM00], which suggests that "researchers may wish to
with injecting new traffic into the network when
acknowledgements are being received, as described in [TCPB98]
[TCPF98]."
9.5. Other aspects of TCP congestion control
Other aspects of TCP congestion control that have not been
in any of the sections above include TCP's recovery from an idle
application-limited period [HPF00].
10. Security
This document has been about the risks associated with
control, or with the absence of congestion control. Section 3.2
discusses the potentials for unfairness if competing flows don't
compatible congestion control mechanisms, and Section 5 considers
dangers of congestion collapse if flows don't use end-to-
congestion control
Floyd, ed. Best Current Practice [Page 15]
RFC 2914 Congestion Control Principles September 2000
Because this document does not propose any specific
control mechanisms, it is also not necessary to present
security measures associated with congestion control. However,
would note that there are a range of security
associated with congestion control that should be considered in
documents
For example, individual congestion control mechanisms should be
robust as possible to the attempts of individual end-nodes to
end-to-end congestion control [SCWA99]. This is a particular
in multicast congestion control, because of the far-
distribution of the traffic and the greater opportunities
individual receivers to fail to report congestion
RFC 2309 also discussed the potential dangers to the Internet
unresponsive flows, that is, flows that don't reduce their
rate in the presence of congestion, and describes the need
mechanisms in the network to deal with flows that are unresponsive
congestion notification. We would note that there is still a
for research, engineering, measurement, and deployment in
areas
Because the Internet aggregates very large numbers of flows, the
to the whole infrastructure of subverting the congestion control of
few individual flows is limited. Rather, the risk to
infrastructure would come from the widespread deployment of
end-nodes subverting end-to-end congestion control
AUTHOR'S
Sally
AT&T Center for Internet Research at ICSI (ACIRI
Phone: +1 (510) 642-4274 x189
EMail: floyd@aciri.
URL: http://www.aciri.org/floyd
Floyd, ed. Best Current Practice [Page 16]
RFC 2914 Congestion Control Principles September 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Floyd, ed. Best Current Practice [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
