congestion
Click on the red underlined text to get to the source
... connections, it seems prudent
to examine the potential effect of real time flows on congestion. In
this document, we perform such an analysis. Note, however, that this
document is not making any recommendations about deployment ...
... deployment to continue. This document expresses our
concern over the lack of effective end-to-end congestion control for
this best-effort voice traffic ...
... protecting some fraction of best-effort VoIP traffic from congestion.
However, these local forms of QoS are not directly visible to the
...
... developing countries, where core links are more likely to be
congested, making congestion control an especially important topic
for developing countries.
...
... effort networks, some concerns arise about the possibilities of
congestion collapse due to a rapid growth in real-time voice traffic ...
... traffic
that does not practice end-to-end congestion control. This document
raises some concerns about fairness, user quality, and the danger of
...
... raises some concerns about fairness, user quality, and the danger of
congestion collapse that would arise from a rapid growth in best-
effort telephony traffic on best-effort networks ...
... The concerns in this document about fairness and the danger of
congestion collapse apply not only to telephony traffic, but also to
video traffic ...
... traffic doesn't
require end-to-end congestion control. Thus, while the concerns in
this document are general, the document focuses on the particular
issue of best-effort audio ...
... Internet was substantially more than the 64 kbps required by the
codec. The primary congestion point along the path of the
demonstration was a 128 kbps access link between an ISP ...
... connection demonstrates, prescribing universal
overprovisioning (or more precisely, provisioning sufficient to avoid
persistent congestion) as the solution to the problem is not an
acceptable generic solution. For example, in regions of the world
where circuit ...
... Internet
links to avoid congestion is likely to be impractical or impossible.
In particular, an over-provisioned core is not by itself sufficient
...
...
In particular, an over-provisioned core is not by itself sufficient
to avoid congestion collapse all the way along the path, because an
over-provisioned core can not address the common problem of
...
... over-provisioned core can not address the common problem of
congestion on the access links. Many access links routinely suffer
...
... access links. Many access links routinely suffer
from congestion. It is important to avoid congestion collapse along
the entire end-to-end ...
... access links routinely suffer
from congestion. It is important to avoid congestion collapse along
the entire end-to-end path, including along the access links ...
... end-to-end path, including along the access links (where
congestion collapse would consist of congested access links wasting
scarce bandwidth ...
... downstream). So an over-provisioned core does not by itself
eliminate or reduce the need for end-to-end congestion avoidance and
control.
...
... control.
There are two possible mechanisms for avoiding this congestion
collapse: call rejection during busy periods, or the use of end-to-
end congestion control ...
... congestion
collapse: call rejection during busy periods, or the use of end-to-
end congestion control. Because there are currently no
acceptance/rejection mechanisms for best-effort traffic in the
...
... Internet, the only alternative is the use of end-to-end congestion
control. This is important even if end-to-end congestion control is
...
... end-to-end congestion
control. This is important even if end-to-end congestion control is
invoked only in those very rare scenarios with congestion in
...
... end-to-end congestion control is
invoked only in those very rare scenarios with congestion in
generally-uncongested access links or networks ...
... occasional periods of high demand, e.g., in the two hours after an
earthquake or other disaster, and this is exactly when it is
important to avoid congestion collapse.
Best-effort traffic ...
... This happy situation is due primarily to low levels of link
utilization in the core, with congestion typically found on lower-
capacity access links, and to the use of end-to-end ...
... capacity access links, and to the use of end-to-end congestion
control in TCP. Most of the traffic on the Internet ...
... TCP self-corrects so that the two ends of a connection reduce the
rate of packet sending if congestion is detected. In the sections
below, we discuss some of the problems caused by persistent, high
packet drop rates.
...
... Congestion Collapse ...
...
One possible problem caused by persistent, high packet drop rates is
that of congestion collapse. Congestion collapse was first observed
during the early growth phase of the Internet ...
... One possible problem caused by persistent, high packet drop rates is
that of congestion collapse. Congestion collapse was first observed
during the early growth phase of the Internet of the mid 1980s
...
... [RFC896], and the fix was provided by Van Jacobson, who developed the
congestion control mechanisms that are now required in TCP
implementations [Jacobson88 ...
... downstream congested
link. If congestion collapse occurs, all traffic slows to a crawl
and nobody gets acceptable packet delivery ...
... delivery or acceptable performance.
Because congestion collapse of this form can occur only for flows
that traverse multiple congested links ...
... flows
that traverse multiple congested links, congestion collapse is a
potential problem in VoIP ...
... TCP. The response of VoIP traffic to congestion works best by taking
into account the congestion control response of TCP ...
... traffic to congestion works best by taking
into account the congestion control response of TCP, as is discussed
in the next subsection.
...
... traffic to the congested link discussed in the
previous section. In this case, the non-congestion-controlled
traffic and congestion-controlled TCP ...
... or multi-player games), and therefore merits a larger share of the
bandwidth in times of high congestion. Our assumption in this
document is that TCP traffic ...
... traffic should be exempt from
end-to-end congestion control due to any claims of inherently more
valuable content. (One could equally logically argue that because
email ...
... instant
messaging are more valuable uses of scarce bandwidth in times of high
congestion.) In fact, the network is incapable of making a judgment
about the relative user value of traffic ...
... IETF to address issues
of congestion control for real time traffic: an upgrade of the RTP
specification, TFRC ...
... RTP Profile for Audio and Video Control, does
not discuss congestion control [RFC1890]. The revised document on
"RTP Profile ...
... Audio and Video Conferences with Minimal Control"
[RFC3551] discusses congestion control in Section 2. [RFC3551] says
the following:
...
... flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or
the number of layers subscribed for a layered multicast session ...
... receivers
"MUST" detect and respond to a persistent high loss rate. Since
congestion collapse can be considered a "danger to the Internet" the
use of "MUST" would be appropriate for RTP ...
...
As mentioned in RFC 3267prop(-> 4867prop), equation-based congestion control is one of
the possibilities for VoIP. TCP ...
... TCP Friendly Rate Control (TFRC) is the
equation-based congestion control mechanism that has been
standardized in the IETF. The TFRC ...
... sending rate in
packets per second in response to congestion. Some audio
applications require a fixed interval of time between packets and
...
... packet size instead of their packet rate in response to
congestion. The congestion control mechanism in this document
cannot be used by those applications; TFRC ...
... packet rate in response to
congestion. The congestion control mechanism in this document
cannot be used by those applications; TFRC-PS ...
... sending rate but vary their packet size in response to
congestion. TFRC-PS will be specified in a later document."
...
...
The Datagram Congestion Control Protocol (DCCP) is a transport
protocol being standardized in the IETF ...
... unreliable flows, with
the application being able to specify either TCP-like or TFRC
congestion control [DCCP03].
...
... CCIDs; these
are CCID 2 for TCP-like congestion control and CCID 3 for TFRC
congestion control. As TFRC ...
... CCID 2 for TCP-like congestion control and CCID 3 for TFRC
congestion control. As TFRC-PS becomes available and goes through
...
... throughput decreases and/or packet loss increases. Absent this, and
in the absence of the response to congestion recommended in this
document, the real-time application is likely to significantly
...
... real-time application is likely to significantly
increase the risk of Internet congestion collapse, thereby adversely
impacting the health of the deployed Internet. If the codec ...
... codec is
capable of reducing its bit rate in response to congestion, this
improves the scaling of the number of VoIP or TCP sessions ...
... bit rate, in some cases adapting their sending rate in response to
congestion indications from the network.
...
... RTP payload format specified in RFC
3267prop(-> 4867prop) use congestion control, though no specific mechanism is
recommended. RFC 3267prop(-> 4867prop) gives "Equation-Based Congestion Control ...
... congestion control, though no specific mechanism is
recommended. RFC 3267prop(-> 4867prop) gives "Equation-Based Congestion Control for
Unicast Applications" as an example of a congestion control ...
... Congestion Control for
Unicast Applications" as an example of a congestion control mechanism
suitable for real-time flows ...
... sending rate that the best-effort
flow is never required to terminate due to congestion, or to reduce
its sending rate in packets per second ...
... Bps an acceptable minimum sending rate for the application,
which can be continued in the face of congestion without terminating
or suspending the application?
...
... sending rate in pps when it adapts to network congestion, thus
reducing the load on the forward path both in Bps and in pps. In
...
... network limitation in fact is in Bps, then all that matters in
terms of congestion is a flow's sending rate on the wire in Bps ...
... Bps is false, then the
sending rate in pps could contribute to congestion even when the
sending rate in Bps ...
... hard to achieve. We would not want to delay the deployment of
congestion control for telephony traffic until such an ideal could be
accomplished. In addition, we note that the current TCP ...
... traffic until such an ideal could be
accomplished. In addition, we note that the current TCP congestion
control mechanisms are themselves not very effective in an
environment where there is a limitation along the reverse path in
pps. While the TCP ...
... data packets, TCP does not include any effective congestion control
mechanisms for the stream of small acknowledgement packets on the
...
... application to terminate:
1) Avoiding congestion collapse, given the possibility of multiple
congested links,
...
... flow might be able to start
sending again, to see if the congestion on the end-to-end path has
changed. This issue has been addressed in a proposal for
...
... end-to-end path has
changed. This issue has been addressed in a proposal for
Probabilistic Congestion Control [PCC].
...
... PCC].
We note that if the congestion indications are in the form of ECN-
marked packets (Explicit Congestion Notification ...
... congestion indications are in the form of ECN-
marked packets (Explicit Congestion Notification), as opposed to
dropped packets, then the answers about when a flow with a minimum
...
... allows routers to explicitly notify end-nodes of congestion by ECN-
marking instead of dropping packets [RFC3168 ...
... marked instead of dropped in the network, then there are no concerns
of congestion collapse or of user quality (for the ECN-capable
traffic ...
... fairness with
competing flows. Second, in regimes with very high congestion, TCP
has a higher sending rate ...
... intervals for measuring the persistent drop rate.
The time period for detecting persistent congestion also affects the
potential synchronization of VoIP ...
... VoIP sessions all terminating or
suspending at the same time in response to shared congestion. If
flows use some randomization in setting the time interval for
...
... flows use some randomization in setting the time interval for
detecting persistent congestion, or use a time interval that is a
function of the connection lifetime ...
...
One simple heuristic for estimating congestion would be to use the
RTCP reported loss rate as an indicator. For example, if the RTCP ...
... connections. Current real time
media encoding and transmission practice ignores congestion
considerations, resulting in the potential for trouble should VoIP
...
... VoIP and TCP users, and the
possibility of sporadic episodes of congestion collapse are some of
the potential problems in this scenario.
...
... IETF community, as a
specific follow-up to RFC 2914 on Congestion Control Principles.
This is not a specific or complete protocol specification ...
... Codecs that are able to vary their bit rate depending on estimates of
congestion can be even more effective in providing good quality
service while maintaining network ...
... the use of ECN, where routers may indicate congestion to end-nodes by
marking packets instead of dropping them. However, ECN ...
... standardized to be used with transport protocols that react
appropriately to marked packets as indications of congestion. VoIP
traffic ...
... traffic that follows the recommendations in this document could
satisfy the congestion-control requirements for using ECN, while VoIP ...
... Deepak Bansal, Hari Balakrishnan, Sally Floyd, and Scott Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001. ...
... Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye, Datagram Congestion Control Protocol (DCCP), internet-draft Work in Progress ...
... S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation- Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000. ...
... V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, August 1988. ...
... Web page on "Measurement Studies of End-to-End Congestion Control in the Internet", URL "http://www.icir.org/floyd/ccmeasure.html ...
... Joerg Widmer, Martin Mauve, and Jan Peter Damm. Probabilistic Congestion Control for Non-Adaptable Flows. Technical Report 3/2001, Department of Mathematics and Computer Science, University of Mannheim. URL ...
... Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168prop ...
... TCP sender can sometimes avoid a retransmit timeout when a packet
is dropped and the congestion window is small. With high packet drop
rates of 0.65 and 0.7, the sending rate in the simulations is
...