Network congestion

Network congestion in data networking and queueing theory is the reduced quality of service that occurs
when a network node or link is carrying more data than it can handle. Typical effects include queueing
delay, packet loss or the blocking of new connections. A consequence of congestion is that an incremental
increase in offered load leads either only to a small increase or even a decrease in network throughput.[1]

Network protocols that use aggressive retransmissions to compensate for packet loss due to congestion can
increase congestion, even after the initial load has been reduced to a level that would not normally have
induced network congestion. Such networks exhibit two stable states under the same level of load. The
stable state with low throughput is known as congestive collapse.

Networks use congestion control and congestion avoidance techniques to try to avoid collapse. These
include: exponential backoff in protocols such as CSMA/CA in 802.11 and the similar CSMA/CD in the
original Ethernet, window reduction in TCP, and fair queueing in devices such as routers and network
switches. Other techniques that address congestion include priority schemes which transmit some packets
with higher priority ahead of others and the explicit allocation of network resources to specific flows
through the use of admission control.

Contents
Network capacity
Congestive collapse
Congestion control
Theory of congestion control
Classification of congestion control algorithms
Mitigation
Practical network congestion avoidance
TCP/IP congestion avoidance
Active queue management
Random early detection
Robust random early detection (RRED)
Flowbased-RED/WRED
Explicit Congestion Notification
Cisco AQM: Dynamic buffer limiting
TCP window shaping
Backward ECN
Side effects of congestive collapse avoidance
Radio links
Short-lived connections
Admission control
See also
References
Bibliography
External links

Network capacity
Network resources are limited, including router processing time and link throughput. Resource contention
may occur on networks in a number of common circumstances. A wireless LAN is easily filled by a single
personal computer.[2] Even on fast computer networks, the backbone can easily be congested by a few
servers and client PCs. Denial-of-service attacks by botnets are capable of filling even the largest Internet
backbone network links, generating large-scale network congestion. In telephone networks, a mass call
event can overwhelm digital telephone circuits.

Congestive collapse
Congestive collapse (or congestion collapse) is the condition in which congestion prevents or limits useful
communication. Congestion collapse generally occurs at choke points in the network, where incoming traffic
exceeds outgoing bandwidth. Connection points between a local area network and a wide area network are
common choke points. When a network is in this condition, it settles into a stable state where traffic demand
is high but little useful throughput is available, packet delay and loss occur and quality of service is
extremely poor.

Congestive collapse was identified as a possible problem by 1984.[3] It was first observed on the early
Internet in October 1986,[4] when the NSFnet phase-I backbone dropped three orders of magnitude from its
capacity of 32 kbit/s to 40 bit/s, which continued until end nodes started implementing Van Jacobson and
Sally Floyd's congestion control between 1987 and 1988.[5] When more packets were sent than could be
handled by intermediate routers, the intermediate routers discarded many packets, expecting the end points
of the network to retransmit the information. However, early TCP implementations had poor retransmission
behavior. When this packet loss occurred, the endpoints sent extra packets that repeated the information lost,
doubling the incoming rate.

Congestion control
Congestion control modulates traffic entry into a telecommunications network in order to avoid congestive
collapse resulting from oversubscription. This is typically accomplished by reducing the rate of packets.
Whereas congestion control prevents senders from overwhelming the network, flow control prevents the
sender from overwhelming the receiver.

Theory of congestion control

The theory on congestion control was pioneered by Frank Kelly, who applied microeconomic theory and
convex optimization theory to describe how individuals controlling their own rates can interact to achieve an
optimal network-wide rate allocation. Examples of optimal rate allocation are max-min fair allocation and
Kelly's suggestion of proportionally fair allocation, although many others are possible.

Let be the rate of flow , be the capacity of link , and be 1 if flow uses link and 0 otherwise. Let
, and be the corresponding vectors and matrix. Let be an increasing, strictly concave function,
called the utility, which measures how much benefit a user obtains by transmitting at rate . The optimal
rate allocation then satisfies
 such that

The Lagrange dual of this problem decouples, so that each flow sets its own rate, based only on a price
signalled by the network. Each link capacity imposes a constraint, which gives rise to a Lagrange multiplier,
. The sum of these multipliers, is the price to which the flow responds.

Congestion control then becomes a distributed optimisation algorithm. Many current congestion control
algorithms can be modelled in this framework, with being either the loss probability or the queueing
delay at link . A major weakness is that it assigns the same price to all flows, while sliding window flow
control causes burstiness that causes different flows to observe different loss or delay at a given link.

Classification of congestion control algorithms

Among the ways to classify congestion control algorithms are:

By type and amount of feedback received from the network: Loss; delay; single-bit or multi-bit
explicit signals
By incremental deployability: Only sender needs modification; sender and receiver need
modification; only router needs modification; sender, receiver and routers need modification.
By performance aspect: high bandwidth-delay product networks; lossy links; fairness;
advantage to short flows; variable-rate links
By fairness criterion: Max-min fairness; proportionally fair; controlled delay

Mitigation
Mechanisms have been invented to prevent network congestion or to deal with a network collapse:

Network scheduler – active queue management which reorders or selectively drops network
packets in the presence of congestion
Explicit Congestion Notification – an extension to IP and TCP communications protocols that
adds a flow control mechanism
TCP congestion control – various implementations of efforts to deal with network congestion

The correct endpoint behavior is usually to repeat dropped information, but progressively slow the repetition
rate. Provided all endpoints do this, the congestion lifts and the network resumes normal behavior. Other
strategies such as slow-start ensure that new connections don't overwhelm the router before congestion
detection initiates.

Common router congestion avoidance mechanisms include fair queuing and other scheduling algorithms,
and random early detection (RED) where packets are randomly dropped as congestion is detected. This
proactively triggers the endpoints to slow transmission before congestion collapse occurs.

Some end-to-end protocols are designed behave well under congested conditions; TCP is a well known
example. The first TCP implementations to handle congestion were described in 1984,[6] but Van Jacobson's
inclusion of an open source solution in the Berkeley Standard Distribution UNIX ("BSD") in 1988 first
provided good behavior.
UDP does not control congestion. Protocols built atop UDP must handle congestion independently.
Protocols that transmit at a fixed rate, independent of congestion, can be problematic. Real-time streaming
protocols, including many Voice over IP protocols, have this property. Thus, special measures, such as
quality of service, must be taken to keep packets from being dropped in the presence of congestion.

Practical network congestion avoidance

Connection-oriented protocols, such as the widely used TCP protocol watch for packet loss, or queuing
delay to adjust their transmission rate. Various network congestion avoidance processes support different
trade-offs.[7]

TCP/IP congestion avoidance

The TCP congestion avoidance algorithm is the primary basis for congestion control on the
Internet.[8][9][10][11][12]

Problems occur when concurrent TCP flows experience tail-drops, especially when bufferbloat is present.
This delayed packet loss interferes with TCP's automatic congestion avoidance. All flows that experience
this packet loss begin a TCP retrain at the same moment – this is called TCP global synchronization.

Active queue management

Active queue management (AQM) is the reordering or dropping of network packets inside a transmit buffer
that is associated with a network interface controller (NIC). This task is performed by the network scheduler.

Random early detection

One solution is to use random early detection (RED) on the network equipment's egress queue.[13][14] On
networking hardware ports with more than one egress queue, weighted random early detection (WRED) can
be used.

RED indirectly signals TCP sender and receiver by dropping some packets, e.g. when the average queue
length is more than a threshold (e.g. 50%) and deletes linearly or cubically more packets,[15] up to e.g.
100%, as the queue fills further.

Robust random early detection (RRED)

The robust random early detection (RRED) algorithm was proposed to improve the TCP throughput against
denial-of-service (DoS) attacks, particularly low-rate denial-of-service (LDoS) attacks. Experiments
confirmed that RED-like algorithms were vulnerable under Low-rate Denial-of-Service (LDoS) attacks due
to the oscillating TCP queue size caused by the attacks.[16]

Flowbased-RED/WRED

Some network equipment is equipped with ports that can follow and measure each flow (flowbased-
RED/WRED) and are thereby able to signal a too big bandwidth flow according to some quality of service
policy. A policy could then divide the bandwidth among all flows by some criteria.
Explicit Congestion Notification

Another approach is to use IP Explicit Congestion Notification (ECN).[17] ECN is used only when two hosts
signal that they want to use it. With this method, a protocol bit is used to signal explicit congestion. This is
better than the indirect packet delete congestion notification performed by the RED/WRED algorithms, but
it requires explicit support by both hosts.[18] ECN coauthor Sally Floyd published detailed information on
ECN, including the version required for Cisco IOS.[13]

When a router receives a packet marked as ECN-capable and anticipates (using RED) congestion, it sets the
ECN flag, notifying the sender of congestion. The sender should respond by decreasing its transmission
bandwidth, e.g., by decreasing the TCP window size (sending rate) or by other means.

Cisco AQM: Dynamic buffer limiting

Cisco Systems (Engine IV and V) has the capability to classify flows as aggressive (bad) or adaptive (good).
It ensures that no flows fill the port queues. DBL can utilize IP ECN instead of packet-delete-
signalling.[19][20]

TCP window shaping

Congestion avoidance can be achieved efficiently by reducing traffic. When an application requests a large
file, graphic or web page, it usually advertises a "window" of between 32K and 64K. This results in the
server sending a full window of data (assuming the file is larger than the window). When many applications
simultaneously request downloads, this data creates a congestion point at an upstream provider by flooding
the queue. By using a device to reduce the window advertisement, the remote servers send less data, thus
reducing the congestion. This technique can reduce network congestion by a factor of 40.

Backward ECN

Backward ECN (BECN) is another proposed congestion mechanism. It uses ICMP source quench messages
as an IP signalling mechanism to implement a basic ECN mechanism for IP networks, keeping congestion
notifications at the IP level and requiring no negotiation between network endpoints. Effective congestion
notifications can be propagated to transport layer protocols, such as TCP and UDP, for the appropriate
adjustments.[21]

Side effects of congestive collapse avoidance

Radio links

The protocols that avoid congestive collapse are often based on the idea that data loss is caused by
congestion. This is true in nearly all cases; errors during transmission are rare. However, this causes WiFi,
3G or other networks with a radio layer to have poor throughput in some cases since wireless networks are
susceptible to data loss due to interference. The TCP connections running over a radio based physical layer
see the data loss and tend to erroneously believe that congestion is occurring.

Short-lived connections
The slow-start protocol performs badly for short connections. Older web browsers created many short-lived
connections and opened and closed the connection for each file. This kept most connections in the slow start
mode, which slowed response times.

To avoid this problem, modern browsers either open multiple connections simultaneously or reuse one
connection for all files requested from a particular server. Initial performance can be poor, and many
connections never get out of the slow-start regime, significantly increasing latency.

Admission control
Admission control requires devices to receive permission before establishing new network connections. If
the new connection risks creating congestion, permission can be denied. One example of this is the use of
Contention-Free Transmission Opportunities (CFTXOPs) in the ITU-T G.hn standard, which provides high-
speed (up to 1 Gbit/s) local area networking over varying wires (power lines, phone lines and coaxial
cables).

See also
Bandwidth management
Bufferbloat – Congestion caused by excessive packet buffering
Cascading failure – System of interconnected parts in which the failure of one or few parts can
trigger the failure of others
Choke exchange
Erlang (unit)
Max-min fairness
Sorcerer's Apprentice Syndrome – A network protocol flaw in the original versions of TFTP
TCP congestion control – Techniques to improve network performance over Transmission
Control Protocol
Teletraffic engineering
Thrashing – Computer constantly exchanging data between memory and storage leaving little
capacity for productive processing
Traffic shaping
Reliability (computer networking)

References
1. (Al-Bahadili, 2012, p. 282) Al-Bahadili, H. (2012). Simulation in computer network design and
modeling: Use and analysis (https://books.google.com/books?id=uNlplf2C03QC&lpg=PA282&d
q=network%20congestion%20occurs%20when%20a%20link%20or%20node%20is%20carryin
g%20so%20much%20data%20that%20its%20quality%20of%20service%20deteriorates.&pg=
PA282#v=onepage&q=network%20congestion%20occurs%20when%20a%20link%20or%20no
de%20is%20carrying%20so%20much%20data%20that%20its%20quality%20of%20service%2
0deteriorates.&f=false). Hershey, PA: IGI Global.
2. den Hartog, F., Raschella, A., Bouhafs, F., Kempker, P., Boltjes, B., & Seyedebrahimi, M.
(2017, November). A Pathway to solving the Wi-Fi Tragedy of the Commons in apartment
blocks (http://unsworks.unsw.edu.au/fapi/datastream/unsworks:50254/bin458a10d9-f568-479c-
a9b5-5c185ef64e78?view=true). In 2017 27th International Telecommunication Networks and
Applications Conference (ITNAC) (pp. 1-6). IEEE.
3. RFC 896 (https://tools.ietf.org/html/rfc896)
 4. Fall, K.R.; Stevens, W.R. (2011). TCP/IP Illustrated, Volume 1: The Protocols (https://books.go
ogle.com/?id=a23OAn5i8R0C) (2 ed.). Pearson Education. p. 739. ISBN 9780132808187.
5. Hafner, Katie. "Sally Floyd, Who Helped Things Run Smoothly Online, Dies at 69" (https://ww
w.nytimes.com/2019/09/04/science/sally-floyd-dead.html). New York Times. New York Times.
Retrieved 5 September 2019.
6. Vinton G. Cerf; Robert E. Kahn (May 1974). "A Protocol for Packet Network
Intercommunication" (https://web.archive.org/web/20160304150203/http://ece.ut.ac.ir/Classpa
ges/F84/PrincipleofNetworkDesign/Papers/CK74.pdf) (PDF). IEEE Transactions on
Communications. 22 (5): 637–648. doi:10.1109/tcom.1974.1092259 (https://doi.org/10.1109%2
Ftcom.1974.1092259). Archived from the original (http://ece.ut.ac.ir/Classpages/F84/Principleo
fNetworkDesign/Papers/CK74.pdf) (PDF) on March 4, 2016.
7. Lee, B.P.; Balan, R.K.; Jacob, L.; Seah, W.K.G.; Ananda, A.L. (2000), "TCP Tunnels: Avoiding
Congestion Collapse", Proceedings 25th Annual IEEE Conference on Local Computer
Networks. LCN 2000, pp. 408–417, doi:10.1109/LCN.2000.891077 (https://doi.org/10.1109%2
FLCN.2000.891077), ISBN 0-7695-0912-6
8. Van Jacobson, Michael J. Karels. Congestion Avoidance and Control (http://citeseer.ist.psu.ed
u/484335.html) (1988). Proceedings of the Sigcomm '88 Symposium, vol.18(4): pp.314–329.
Stanford, CA. August, 1988. This paper originated many of the congestion avoidance
algorithms used in TCP/IP.
9. RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms
10. RFC 2581 - TCP Congestion Control
11. RFC 3390 - TCP Increasing TCP's Initial Window
12. TCP Congestion Avoidance Explained via a Sequence Diagram (http://www.eventhelix.com/Re
altimeMantra/Networking/TCP_Congestion_Avoidance.pdf)
13. Sally Floyd: RED (Random Early Detection) Queue Management (http://www.icir.org/floyd/red.
html)
14. Sally Floyd, Van Jacobson. Random Early Detection Gateways for Congestion Avoidance (htt
p://citeseer.ist.psu.edu/462978.html) (1993). IEEE/ACM Transactions on Networking, vol.1(4):
pp.397–413. Invented Random Early Detection (RED) gateways.
15. An Analytical RED Function Design Guaranteeing Stable System Behavior,
CiteSeerX 10.1.1.105.5995 (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.59
95), "...The advantage of this function lies not only in avoiding heavy oscillations but also in
avoiding link under-utilization at low loads. The applicability of the derived function is
independent of the load range, no parameters are to be adjusted. Compared to the original
linear drop function applicability is extended by far...Our example with realistic system
parameters gives an approximation function of the cubic of the queue size..."
16. Zhang, Changwang; Yin, Jianping; Cai, Zhiping; Chen, Weifeng (2010). "RRED: Robust RED
Algorithm to Counter Low-rate Denial-of-Service Attacks" (https://sites.google.com/site/cwzhan
gres/home/files/RREDRobustREDAlgorithmtoCounterLow-rateDenial-of-ServiceAttacks.pdf?att
redirects=0) (PDF). IEEE Communications Letters. IEEE. 14 (5): 489–491.
doi:10.1109/LCOMM.2010.05.091407 (https://doi.org/10.1109%2FLCOMM.2010.05.091407).
17. RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP
18. Comparative study of RED, ECN and TCP Rate Control (1999) (http://citeseer.ist.psu.edu/baga
l99comparative.html)
19. "Active Queue Management" (https://web.archive.org/web/20080821192051/http://www.cisco.c
om/univercd/cc/td/doc/product/lan/cat4000/12_1_19/config/qos.htm#1271743). Archived from
the original (http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_1_19/config/qos.
htm#1271743) on 2008-08-21. Retrieved 2010-11-26.
20. Enabling Dynamic Buffer Limiting (http://www.cisco.com/univercd/cc/td/doc/product/lan/cat400
0/12_1_19/config/qos.htm#1271759)
21. A proposal for Backward ECN for the Internet Protocol (http://tools.ietf.org/html/draft-salim-jhsb
nns-ecn-00)

"Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans,
Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
RFC 2914 - Congestion Control Principles, Sally Floyd, September, 2000
RFC 896 - "Congestion Control in IP/TCP", John Nagle, 6 January 1984
Introduction to Congestion Avoidance and Control (http://ee.lbl.gov/papers/congavoid.pdf), Van
Jacobson and Michael J. Karels, November, 1988

Bibliography
John Evans; Clarence Filsfils (2007). Deploying IP and MPLS QoS for Multiservice Networks:
Theory and Practice. Morgan Kaufmann. ISBN 978-0-12-370549-5.

External links
Nagle, J. RFC 896: Congestion control in IP/TCP internetworks (1984)
Floyd, S. RFC 2914: Congestion control principles (2000)
Floyd, S. and K. Fall, Promoting the Use of End-to-End Congestion Control in the Internet (htt
p://www.aciri.org/floyd/end2end-paper.html) (IEEE/ACM Transactions on Networking, August
1999)
Sally Floyd, On the Evolution of End-to-end Congestion Control in the Internet: An Idiosyncratic
View (http://www.ima.umn.edu/talks/workshops/10-22-24.99/floyd/floyd.pdf) (IMA Workshop on
Scaling Phenomena in Communication Networks, October 1999) (pdf format)
Linktionary term: Queuing (http://www.linktionary.com/q/queuing.html)
Pierre-Francois Quet, Sriram Chellappan, Arjan Durresi, Mukundan Sridharan, Hitay Ozbay,
Raj Jain, " Guidelines for optimizing Multi-Level ECN, using fluid flow based TCP model" (htt
p://www.cse.wustl.edu/~jain/papers.html)
Sally Floyd, Ratul Mahajan, David Wetherall: RED-PD: RED with Preferential Dropping (http://
www.cs.washington.edu/homes/ratul/red-pd/)
A Generic Simple RED Simulator for educational purposes by Mehmet Suzen (https://code.goo
gle.com/p/guduz/)
Approaches to Congestion Control in Packet Networks (https://web.archive.org/web/20140221
123729/http://utopia.duth.gr/~emamatas/jie2007.pdf)
Papers in Congestion Control (http://www.ecse.rpi.edu/Homepages/shivkuma/research/cong-p
apers.html)
Random Early Detection Homepage (http://www.icir.org/floyd/red.html)
Explicit Congestion Notification Homepage (http://www.icir.org/floyd/ecn.html)
TFRC Homepage (http://www.icir.org/tfrc/)
AIMD-FC Homepage (https://web.archive.org/web/20090113204941/http://www.ccs.neu.edu/h
ome/ladrian/abstract/aimdfc.html)
(http://www.visualland.net/tcp_histrory.php?simu=tcp_fast_recovery&protocol=TCP&title=5.%2
0Fast%20recovery&ctype=1)permanent dead link] TCP congestion control simulation: Fast
recovery
Recent Publications in low-rate denial-of-service (DoS) attacks (https://sites.google.com/site/c
wzhangres/home/posts/recentpublicationsinlow-ratedosattacks)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Network_congestion&oldid=958834692"

This page was last edited on 25 May 2020, at 23:19 (UTC).

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.