Fact-checked by Grok 2 weeks ago

Network congestion

Network congestion in computer networks is a phenomenon that arises when the aggregate demand for network resources, such as bandwidth on links or processing at nodes, exceeds the available capacity, leading to a reduction in the network's ability to deliver useful data throughput effectively.^[1] This condition manifests as an imbalance where increased traffic load paradoxically decreases overall performance, potentially culminating in severe issues like congestive collapse, where nearly all packets are dropped or undelivered, wasting significant bandwidth.^[1] The primary causes of network congestion include unresponsive or aggressive data flows that do not adapt to network feedback, such as UDP-based applications that transmit at constant rates without throttling during overload, and scenarios where multiple connections from a single source overwhelm shared resources.^[1] Other contributing factors encompass sudden spikes in user demand, insufficient bandwidth provisioning relative to traffic growth, hardware limitations in routers or switches, and inefficient routing configurations that funnel disproportionate traffic through bottlenecks.^[2] Effects are pronounced and multifaceted: packets experience queuing delays as they wait in buffers, leading to higher latency; excess traffic overflows buffers, causing packet loss; and in extreme cases, the network's utilization plummets, sometimes to as low as 10% of capacity, starving even compliant flows of service.^[1] These impacts degrade quality of service for applications, from web browsing to real-time video streaming, and can propagate unfairness where aggressive flows dominate at the expense of others.^[1] To mitigate network congestion, protocols like TCP incorporate end-to-end congestion control mechanisms that detect signs of overload—such as packet losses or delays—and dynamically adjust transmission rates to maintain stability and fairness. Complementary router-based techniques, including active queue management (e.g., Random Early Detection), proactively signal impending congestion to endpoints before buffers fill completely. Ongoing research explores advanced algorithms, such as those in high-speed networks or satellite systems, emphasizing proactive avoidance through topology-aware routing and closed-loop feedback to prevent rather than merely react to overload.^[3]

Fundamentals

Definition and Causes

Network congestion occurs when the demand for network resources exceeds their available capacity, resulting in degraded performance such as increased packet delays, losses, and reduced throughput.^[4] This phenomenon arises primarily in data networks where nodes, links, or buffers become overwhelmed by incoming traffic that surpasses the processing or transmission limits of the infrastructure.^[5] The primary causes of network congestion include high traffic volumes from bursty sources, insufficient bandwidth allocation, routing inefficiencies, and protocol mismatches. Bursty traffic, such as sudden data surges from applications like file transfers over Ethernet, can overload links by sending packets in rapid clusters that exceed momentary capacity.^[6] Insufficient bandwidth allocation happens when network links or channels are provisioned below the sustained demand, leading to persistent queuing at bottlenecks.^[7] Routing inefficiencies, including suboptimal path selections or loops in routing tables, direct disproportionate traffic through limited segments, amplifying local overloads.^[8] Protocol mismatches, such as incompatible retransmission strategies between endpoints, can exacerbate the issue by triggering unnecessary duplicate packets that compound the load.^[9] Network congestion was first prominently observed in the early ARPANET during the 1980s, particularly in a major incident in October 1986, where throughput plummeted due to exponential retransmissions from poorly tuned TCP timers amid growing traffic.^[6] This event highlighted how unchecked retransmission backoffs could cascade into widespread degradation across the network.^[9] A foundational model for understanding network congestion draws from queueing theory, specifically Little's Law, which relates the long-term average number of items in a system to the arrival rate and average time spent in the system: L = \lambda W, where L is the average queue length, \lambda is the average arrival rate of packets, and W is the average waiting time per packet. In network contexts, this law applies to router queues, illustrating how increased arrival rates \lambda during overload lead to longer delays W and larger queues L, thereby quantifying the buildup central to congestion dynamics.^[10]

Network Capacity Limits

Network capacity is defined as the maximum sustainable data rate that a network link or path can reliably transmit, typically measured in bits per second (bps). This limit arises from the inherent constraints of the physical layer, including the transmission medium's properties, such as the signal propagation speed in fiber optics or copper wires, which set the fundamental link speed. For instance, Ethernet standards specify link speeds ranging from 10 Mbps to 400 Gbps, directly bounding the capacity of individual segments.^[11]^[12] Several factors influence overall network capacity beyond raw link speed. Buffer sizes in routers and switches play a critical role, as they must accommodate temporary traffic surges without excessive packet loss; the traditional guideline sets buffer depth to the bandwidth-delay product to prevent underutilization during bursts. Router processing power, including the speed of packet forwarding engines and header analysis, can create bottlenecks if unable to handle line-rate traffic, particularly in high-speed environments where software-based processing falls short of hardware acceleration needs. In legacy shared-medium networks like early Ethernet, contention among multiple devices further reduces effective capacity, as protocols such as CSMA/CD introduce collisions and backoff delays that limit throughput to approximately 75% of nominal link speed under moderate load.^[13]^[14]^[15] A key metric for assessing capacity in end-to-end paths is the bandwidth-delay product (BDP), calculated as the product of the link bandwidth (in bps) and the round-trip time (RTT) (in seconds), representing the amount of data "in flight" needed to fully utilize the pipe. BDP becomes particularly critical in high-latency networks, such as satellite or long-haul fiber links with RTTs exceeding 100 ms, where a 10 Gbps link might require buffers holding 125 MB (1 Gbit) to avoid idling. This metric highlights how delay amplifies capacity demands, influencing protocol window sizes in transport layers.^[11] Capacity limits often manifest as bottlenecks in specific network segments, with access networks—such as DSL or cable modem connections—typically constraining end-user throughput to 100 Mbps or less, far below the terabit-scale capacities of core backbone links using dense wavelength-division multiplexing. In contrast, core networks prioritize overprovisioning to handle aggregated traffic, but multiplexing techniques differentiate their efficiency: time-division multiplexing (TDM) allocates fixed slots, yielding predictable but underutilized capacity for bursty traffic, whereas statistical multiplexing in packet-switched networks exploits traffic variability to achieve higher utilization, potentially approaching 80-90% efficiency under Poisson-like arrivals as theorized in early packet-switching models.^[16]^[17]^[18]

Effects of Congestion

Congestive Collapse

Congestive collapse refers to a catastrophic failure state in packet-switched networks where uncontrolled retransmissions of lost packets create a positive feedback loop, causing network throughput to plummet to near zero despite increasing offered load.^[19] This phenomenon was first systematically described and termed by Van Jacobson in his 1988 paper on congestion avoidance, highlighting how aggressive retransmission strategies in early TCP implementations exacerbated congestion rather than alleviating it.^[19] The process unfolds in distinct stages, beginning with initial overload where the aggregate traffic demand exceeds the network's capacity, leading to buffer overflows and packet drops at routers.^[19] Dropped packets trigger retransmissions from end hosts, which, without proper congestion signaling, amplify the load as each lost packet generates multiple retries, resulting in exponential growth of traffic.^[19] This escalation causes router queues to repeatedly overflow, further increasing drop rates and propagating the slowdown across the entire network, ultimately rendering it unresponsive to legitimate traffic.^[19] A prominent historical example occurred in the ARPANET in October 1986, when congestion on a key 32 kbps link between Lawrence Berkeley Laboratory and UC Berkeley caused throughput to drop from 32 kbps to as low as 40 bps, marking the first major Internet congestion collapse.^[19] This event was resolved through the rapid deployment of initial TCP congestion control mechanisms, including slow-start and congestion avoidance algorithms developed by Van Jacobson between 1987 and 1988, which stabilized the network by throttling transmission rates in response to detected congestion.^[19] A key indicator of impending congestive collapse is the "knee point" in the offered load versus throughput graph, where throughput begins to deviate sharply from linear growth, signaling the onset of instability as minor load increases trigger disproportionate drops in effective capacity.^[19]

Performance Impacts

Network congestion manifests in several key performance degradations that affect user experience and application efficiency. Primarily, it causes increased latency through queuing delays at network bottlenecks, where packets wait in buffers before transmission, often extending round-trip times from milliseconds to seconds in severe cases. Jitter, or the variance in packet delay, arises from fluctuating queue lengths, leading to inconsistent arrival times that disrupt time-sensitive communications. Packet loss rates rise as buffers overflow, forcing routers to drop excess packets, while goodput—the effective throughput of useful data—declines due to retransmissions and reduced overall link utilization, sometimes falling below 50% of available bandwidth during peaks. These effects are quantified in standard evaluation metrics for congestion control, emphasizing the trade-offs between throughput maximization and delay minimization.^[20] In real-time applications, these degradations have pronounced impacts. For Voice over IP (VoIP), elevated latency, jitter exceeding 30 ms, and packet loss rates above 1% significantly lower Mean Opinion Score (MOS) values, dropping from excellent ratings (MOS ≥4) to poor (MOS <3.2), as impairments like bursty losses and round-trip delays over 150 ms degrade perceived conversational quality.^[21] Video streaming suffers from frequent buffering events, where congestion disrupts TCP's bandwidth probing, causing adaptive bitrate algorithms to underestimate capacity and leading to playback interruptions; studies show streaming players often achieve less than 50% of fair-share throughput, prolonging startup times and rebuffering ratios.^[22] Additionally, in mixed traffic environments, TCP flows exhibit unfairness, with short or low-latency flows receiving disproportionately low throughput—up to an order of magnitude less than bulk transfers—due to tail-drop queue behaviors in switches that synchronize losses against fewer flows during congestion.^[23] Performance impacts are commonly measured using tools and budgets tailored to specific contexts. The iPerf tool enables active throughput testing under controlled congestion by simulating TCP or UDP streams between endpoints, revealing goodput reductions and loss patterns in real networks. In real-time systems like videoconferencing, end-to-end delay budgets are strictly limited to under 150 ms, allocating around 20 ms for processing and queuing; congestion violates these by inflating network delays, necessitating larger replay buffers that further compound jitter. Economically, such degradations during peak e-commerce periods like Black Friday result in substantial losses, with 42% of e-commerce companies losing more than $6 million annually due to internet disruptions—including congestion-induced slowdowns—through abandoned carts and reduced conversions, as slow-loading sites prompt 53% of users to forgo purchases if pages take more than 3 seconds to load (as of 2018).^[24]^[25]^[26]

Congestion Control Principles

Theoretical Foundations

Network congestion control can be modeled as a closed-loop feedback system, where end-hosts adjust their transmission rates based on congestion signals from the network, such as packet loss or queueing delays, to maintain stability and efficient resource utilization.^[27] This framework treats the network as a dynamical system governed by ordinary differential equations (ODEs) that describe source rate adjustments and link price updates, with feedback propagating through routing matrices that interconnect multiple flows and bottlenecks.^[27] The analogy to proportional-integral (PI) control is particularly apt, as source algorithms often incorporate proportional terms responsive to instantaneous congestion (e.g., rate reductions proportional to loss) and integral terms that accumulate feedback over time to eliminate steady-state errors, ensuring convergence to a stable operating point.^[27] Fluid flow approximations provide a continuous-time abstraction of discrete packet-level dynamics, simplifying analysis of TCP-like protocols by modeling rates as fluids rather than packets.^[27] A seminal model for TCP Reno's congestion avoidance phase derives the steady-state throughput as approximately \frac{C \cdot \mathrm{MSS}}{\mathrm{RTT} \sqrt{p}}, where C is a constant (around 1.22 for random losses), MSS is the maximum segment size, RTT is the round-trip time, and p is the packet loss probability; this equation emerges from assuming linear window growth interrupted by multiplicative decreases on loss events, yielding a sawtooth pattern whose average slope balances the loss rate.^[28] Such models capture the inverse relationship between loss and throughput, enabling predictions of equilibrium behavior without simulating every packet transmission.^[28] At equilibrium, congestion control allocates rates to maximize aggregate user utility subject to link capacity constraints, formulated as \max \sum_i U_i(x_i) s.t. R x \leq c, where U_i is the utility function for flow i, x is the rate vector, R is the routing matrix, and c are capacities.^[27] Kelly's proportional fairness criterion achieves this by solving \max \sum_r w_r \log x_r s.t. A x \leq C, using shadow prices (Lagrange multipliers) to price congestion and guide decentralized rate adjustments, ensuring fairness where no flow can increase utility without decreasing others proportionally.^[29] This framework decomposes into primal (source-side) and dual (network-side) problems, with equilibria characterized by Karush-Kuhn-Tucker conditions linking marginal utilities to congestion prices.^[29] Stability in multi-link networks requires conditions ensuring convergence despite propagation delays and interactions among flows.^[27] Using Lyapunov functions, such as V(z) = \frac{1}{2} (z - z^*)^T \begin{bmatrix} K^{-1} & 0 \\ 0 & \Gamma^{-1} \end{bmatrix} (z - z^*), global asymptotic stability holds if the routing matrix has full row rank and rates remain positive, with derivative \dot{V} \leq 0 guaranteeing non-increase.^[27] Delay effects are bounded by criteria like \max_i \tau_i \kappa_i \cdot \max_l g'_l(y_l^*) \leq \pi / (2 N L) for primal algorithms, where \tau_i is delay, \kappa_i is gain, and N, L are numbers of nodes and links, preventing oscillations via Nyquist stability analysis that avoids encirclements of the critical point -1 in the complex plane.^[27] These conditions highlight the role of gain tuning and delay margins in achieving robust convergence across topologies.^[27]

Algorithm Classifications

Congestion control algorithms are categorized along multiple dimensions to reflect their operational strategies, feedback dependencies, and resource allocation goals. These classifications derive from foundational principles in network theory, such as ensuring stability and preventing congestive collapse through responsive rate adjustments.^[30] A primary distinction lies between end-to-end and network-assisted approaches. End-to-end congestion control operates solely at the communicating hosts, where endpoints detect and respond to congestion using implicit signals like packet losses or round-trip time variations, without relying on intermediate devices.^[30] The Transmission Control Protocol (TCP) exemplifies this host-based method, adjusting its congestion window based on end-system observations to throttle transmission rates during overload.^[31] In contrast, network-assisted congestion control incorporates explicit support from routers or switches, which provide feedback to guide endpoint behavior.^[30] Explicit Congestion Notification (ECN), for instance, enables routers to mark packets indicating congestion onset, allowing endpoints to reduce rates proactively while avoiding drops. Another key classification separates open-loop from closed-loop strategies, often applied in contexts like Asynchronous Transfer Mode (ATM) networks. Open-loop methods prevent congestion without end-to-end feedback, typically through upfront resource reservation or fixed-rate policing to maintain steady transmission regardless of network state.^[32] Closed-loop approaches, however, depend on feedback loops to dynamically adjust sender rates in response to observed conditions, enabling adaptation to varying loads.^[32] Within closed-loop systems, rate-based schemes directly modulate the transmission rate—increasing it under light load and decreasing it during congestion—while credit-based mechanisms allocate "credits" to senders, limiting output based on receiver or network grants to enforce flow control.^[32] Rate-based methods are favored for their scalability in high-speed environments, as they avoid per-flow queuing complexities inherent in credit-based designs.^[32] Congestion detection methods further classify algorithms as loss-based or delay-based. Loss-based techniques infer congestion from packet drops, triggering multiplicative rate reductions to clear queues, as seen in early TCP implementations that treat losses as primary overload indicators.^[33] Delay-based algorithms, conversely, monitor increases in round-trip time (RTT) to detect queue buildup before losses occur, aiming to keep utilization below capacity for smoother performance.^[33] TCP Vegas represents a seminal delay-based approach, estimating available bandwidth via expected and actual RTTs to adjust the congestion window conservatively; it delivers 40-70% higher throughput and one-fifth to one-half the losses relative to loss-based TCP Reno across diverse topologies.^[34] Fairness classifications address how algorithms apportion bandwidth among competing flows, guided by IETF evaluation criteria. Max-min fairness prioritizes equity by maximizing the lowest flow rate, then the next lowest, and so on, until link capacity is exhausted, ensuring no flow is unduly starved.^[35] Weighted fairness generalizes this by incorporating flow-specific weights, often via proportional allocation that balances aggregate throughput with individual protections, as in utility-based models.^[35] These notions underpin IETF standards for congestion control, requiring algorithms to approximate TCP-compatible sharing to avoid unfair dominance by aggressive flows.^[30]

Avoidance and Mitigation Strategies

General Avoidance Methods

Traffic shaping and policing are fundamental techniques for regulating data flow to prevent bursts from overwhelming network resources. Traffic shaping smooths out irregular traffic patterns by buffering excess packets and releasing them at a controlled rate, while policing enforces rate limits by discarding or marking non-conforming packets. A prominent example is the leaky bucket algorithm, which models traffic regulation using a virtual bucket with a constant leak rate r (tokens per unit time) and finite depth b; incoming packets consume tokens from the bucket, allowing bursts up to b but enforcing the long-term rate r. This mechanism, originally described by Jonathan Turner, effectively mitigates congestion by converting bursty inputs into steady outputs without requiring end-to-end coordination.^[36] Load balancing distributes traffic across multiple paths or resources to avoid bottlenecks on any single route. Equal-cost multi-path (ECMP) routing achieves this by hashing packet headers to select among equivalent-cost paths in IP networks, enabling parallel utilization of links for improved throughput and resilience. Similarly, anycast routing assigns the same IP address to multiple geographically dispersed servers, directing client requests to the nearest instance via BGP, which inherently balances load and reduces congestion during traffic spikes. These methods enhance overall network efficiency by spreading flows dynamically without altering underlying protocols.^[37] Capacity planning involves provisioning sufficient bandwidth to handle anticipated loads, often through overprovisioning where core network capacity exceeds edge demands. Monitoring tools like Simple Network Management Protocol (SNMP) support this by polling devices for metrics such as interface utilization and error rates, enabling proactive adjustments to prevent overload. Such strategies prioritize redundancy to maintain performance during peak usage.^[38] Protocol-independent prioritization classifies traffic into service classes to allocate resources preferentially, reducing the impact of congestion on critical flows. Differentiated Services (DiffServ) implements this via the DS field in IP headers, marking packets with codepoints for behaviors like Expedited Forwarding (EF), which provides low-latency service for real-time applications such as voice, and Assured Forwarding (AF), which offers varying drop priorities for data traffic to ensure delivery assurances. By applying per-hop behaviors at routers, DiffServ enables scalable QoS without state maintenance, complementing avoidance methods like active queue management at edges.^[39]

TCP/IP Congestion Mechanisms

TCP congestion control mechanisms are end-to-end algorithms implemented at the transport layer to prevent network overload by dynamically adjusting the transmission rate based on inferred congestion signals, primarily packet loss and delay, as classified among loss-based approaches.^[20] These mechanisms, first introduced by Van Jacobson in 1988, rely on the sender maintaining a congestion window (cwnd) to limit the amount of unacknowledged data in flight, ensuring the effective throughput does not exceed the available bandwidth while probing for more capacity.^[6] The core idea is to balance aggressiveness in utilizing bandwidth with conservatism in response to congestion indicators, preventing global synchronization of retransmissions that could lead to congestive collapse.^[20] Central to these mechanisms are key parameters such as the congestion window (cwnd), which represents the sender's estimate of the network's capacity in bytes or segments, and the slow start threshold (ssthresh), which delineates the boundary between exploratory and conservative phases of window growth.^[20] The sender transmits new data up to the minimum of cwnd and the receiver's advertised window. Additionally, accurate round-trip time (RTT) estimation is crucial for timing retransmissions and pacing, using Jacobson's algorithm that computes a smoothed RTT (SRTT) via an exponential weighted moving average: SRTT ← (1 - α) * SRTT + α * RTT, where α = 0.125, and incorporates RTT variance (RTTVAR) for robustness: RTTVAR ← (1 - β) * RTTVAR + β * |RTT - SRTT|, with β = 0.25, to set the retransmission timeout (RTO) as SRTT + 4 * RTTVAR.^[6] This adaptive estimation allows TCP to handle varying network conditions without spurious timeouts.^[40] The operation proceeds in phases starting with slow start, where cwnd begins at a small value (typically 2-10 segments) and doubles approximately every RTT by incrementing cwnd by the sender's maximum segment size (SMSS) for each ACK received acknowledging new data, achieving exponential growth until cwnd reaches ssthresh or congestion is detected.^[20] Upon reaching ssthresh, the protocol enters congestion avoidance, linearly increasing cwnd by roughly SMSS per RTT—either by adding SMSS per ACK or using the formula cwnd ← cwnd + (SMSS² / cwnd)—to cautiously probe for additional bandwidth without overshooting.^[20] Congestion detection triggers multiplicative decrease: ssthresh is set to at most half the current flight size (bytes outstanding), and cwnd is reduced accordingly.^[20] To handle losses more efficiently, TCP incorporates fast retransmit and fast recovery. Fast retransmit occurs when three duplicate ACKs arrive, indicating a likely single packet loss, prompting immediate retransmission of the missing segment without awaiting the RTO expiration.^[20] Fast recovery then inflates cwnd to ssthresh + 3 * SMSS to maintain throughput during recovery, incrementing it by SMSS for each additional duplicate ACK, and deflates it back to ssthresh upon receipt of a new ACK, avoiding the full slow start reset.^[20] These phases form the basis of successive TCP variants, standardized in RFC 5681, which obsolete earlier specifications like RFC 2581.^[20] TCP Tahoe, an early implementation from Jacobson's work, resets cwnd to one segment on any loss (timeout or fast retransmit) and enters slow start, providing basic but conservative recovery suitable for moderate networks.^[6] TCP Reno improves this by invoking fast recovery on fast retransmit, halving ssthresh and setting cwnd to ssthresh + 3 * SMSS, but it struggles with multiple losses in one window, often falling back to timeouts.^[20] TCP NewReno addresses this limitation by tracking a recovery point via partial ACKs during fast recovery, retransmitting additional lost segments as they are inferred and handling multiple losses without repeated window reductions, as specified in RFC 6582.^[41] For high-speed and long-distance networks with large bandwidth-delay products (BDP)—the product of available bandwidth and RTT, representing the volume of data that can be in flight—standard Reno underutilizes capacity due to its linear growth.^[42] Algorithms like CUBIC, standardized in RFC 9438, mitigate this as a hybrid loss- and delay-based approach, using a cubic function for cwnd growth: cwnd(t) = C * (t - K)³ + W_max, where t is time since last congestion, K is derived from the window at loss, C=0.4, and W_max is the maximum window achieved, enabling aggressive growth in the convex region post-loss and concave probing near the peak for better BDP utilization and RTT-fairness among flows.^[42] CUBIC reduces the window by a factor of 0.7 on loss (versus Reno's 0.5) to balance scalability and compatibility, making it widely adopted in Linux kernels for modern high-BDP environments like data centers.^[42]

Active Queue Management Techniques

Active Queue Management (AQM) techniques employ router-based strategies to detect and signal impending congestion by manipulating queues, such as through probabilistic packet drops or marks, before buffers overflow. This proactive approach prevents bufferbloat—the excessive queuing delays caused by oversized buffers—while sustaining high link utilization and low latency for responsive traffic like TCP.^[43] By intervening early, AQM allows endpoints to adjust sending rates gradually, mitigating the abrupt packet losses and global synchronization typical of passive tail-drop queuing.^[44] The foundational AQM method is Random Early Detection (RED), introduced by Floyd and Jacobson in 1993 to enable congestion avoidance in packet-switched networks. RED estimates congestion via an exponentially weighted moving average of the queue length, given by q_{\text{avg}} = (1 - w_q) q_{\text{avg}} + w_q q(t), where w_q is a low-pass filter weight (often around 0.002) and q(t) is the current queue size.^[44] Packets pass through unchanged if q_{\text{avg}} falls below a minimum threshold (

\text{min_th}

); drops occur with increasing probability between

\text{min_th}

and a maximum threshold (

\text{max_th}

), linearly ramping from 0 to a small maximum drop probability (

\text{max_p}

, typically 0.02); and certain drops apply above

\text{max_th}

. This design desynchronizes TCP flows, preventing them from simultaneously reducing windows during bursts, and promotes equitable bandwidth sharing.^[44] RFC 2309 later endorsed RED as a best practice for queue management, highlighting its role in preserving Internet performance through early signaling.^[45] Variants of RED address specific limitations in robustness and fairness. Robust RED (RRED) enhances RED's stability against disruptions like low-rate denial-of-service attacks by monitoring packet arrival patterns and adaptively tuning drop probabilities to filter aggressive traffic without inducing flow synchronization. This makes RRED particularly effective in maintaining TCP throughput under adversarial conditions, where standard RED might falter due to parameter sensitivity. Weighted RED (WRED), a class-based extension, applies differentiated thresholds and drop probabilities according to IP precedence or DSCP markings, prioritizing higher-class traffic to ensure per-class fairness and reduce bias against bursty sources.^[46] For per-flow fairness, Flow Random Early Drop (FRED)—a stateful variant—tracks active flows' queue occupancy and weights drops inversely with a flow's recent activity, penalizing bandwidth hogs while protecting shorter or less aggressive flows from starvation.^[47] Deployment of these techniques occurs widely in enterprise and core routers, with WRED integrated into Cisco IOS since the late 1990s to support differentiated services. Configuration involves setting class-specific parameters, such as lower

\text{min_th}

for lower-priority traffic, enabling routers to manage mixed workloads without one class monopolizing resources. Evaluations demonstrate that RED and its variants enhance TCP fairness over drop-tail mechanisms; for instance, RED reduces variance in throughput among multiple TCP flows by up to 50% in simulated bottlenecks, as bursty flows trigger earlier backoffs without locking out others.^[46]^[44] Despite challenges in parameter tuning, these methods remain influential, informing modern AQMs while directly countering congestion-induced inequities in IP networks.^[43]

Explicit Congestion Notification

Explicit Congestion Notification (ECN) enables routers to inform endpoints of network congestion by marking packets rather than discarding them, thereby avoiding the retransmission overhead associated with packet loss. Defined in RFC 3168, ECN repurposes two bits in the IP header—the ECN field within the IPv4 Type of Service (TOS) octet or the IPv6 Traffic Class octet—to convey congestion signals. These bits support four codepoints: 00 for Not-ECN-Capable Transport (Not-ECT), indicating packets that should be treated as in traditional IP; 01 and 10 for ECN-Capable Transport (ECT(1) and ECT(0), respectively), signaling that the transport supports ECN; and 11 for Congestion Experienced (CE), which routers set to notify of congestion.^[48] In operation, endpoints negotiate ECN capability during connection establishment, such as via the SYN and SYN-ACK flags in TCP. When a router experiences congestion—typically detected through mechanisms like Random Early Detection (RED)—it probabilistically sets the CE codepoint on ECT-marked packets instead of dropping them, preserving packet delivery while signaling the issue. The receiving endpoint echoes this congestion indication back to the sender by setting the ECN-Echo (ECE) flag in acknowledgment (ACK) packets, prompting the sender to reduce its transmission rate, usually by halving the congestion window as in loss-based congestion control. To confirm this reduction and halt persistent ECE feedback, the sender sets the Congestion Window Reduced (CWR) flag in subsequent data packets, providing reverse-direction signaling often referred to as backward ECN. ECN integrates with active queue management by using marking thresholds in queues to proactively signal moderate congestion before drops become necessary.^[49]^[50] Extensions to ECN address specific environments, such as data centers. Data Center TCP (DCTCP) aggressively scales ECN by having switches mark packets above a shallow queue threshold and senders adjust their congestion window proportionally to the fraction of CE-marked packets observed over recent ACKs, enabling finer-grained control. This approach maintains high throughput while keeping queue lengths low—typically under 65 packets at 10 Gbps—reducing buffer occupancy by up to 90% compared to standard TCP and minimizing latency for short, latency-sensitive flows.^[51]^[52] ECN offers significant benefits for loss-sensitive applications by eliminating unnecessary packet drops, which lowers retransmission delays and improves overall performance in environments with bursty traffic. It has seen broad adoption, including native support in IPv6 via the Traffic Class field as outlined in RFC 3168, and integration into modern protocols like QUIC, where RFC 9000 specifies ECN verification during path setup and feedback via ACK frames to enable precise congestion control without head-of-line blocking.^[53]^[54]^[55]

Specialized Considerations

Challenges in Wireless and Short Connections

In wireless networks, such as those based on IEEE 802.11 standards, high bit error rates due to signal interference or fading are often misinterpreted by TCP as signs of network congestion, leading to unnecessary reductions in the congestion window and degraded throughput.^[56] This misinterpretation occurs because traditional TCP variants like Reno rely primarily on packet loss as a congestion signal, without distinguishing between corruption-induced losses and true queue overflows.^[57] To address this, extensions like TCP with Selective Acknowledgments (SACK) and Forward Acknowledgment (FACK) enable more precise loss recovery by allowing receivers to report non-contiguous received segments, thus avoiding spurious retransmissions and better isolating error losses from congestion.^[58]^[59] Mobile radio links introduce additional challenges through highly variable link capacities, caused by factors like handovers, fading, or resource scheduling in cellular networks, which can fluctuate rapidly between high and low bandwidth states.^[60] Standard TCP's aggressive response to detected losses—such as halving the congestion window—can exacerbate underutilization in these environments, as the protocol may overly conservative rate adjustments prevent it from adapting quickly to capacity improvements, resulting in prolonged periods of low throughput.^[61] For instance, in low-delay cellular scenarios, early exits from slow start can leave significant bandwidth unused, particularly when link variability triggers frequent loss events mistaken for congestion.^[60] Short-lived TCP connections, often termed "mice" flows in contrast to long "elephant" flows, face performance issues in congested networks due to the overhead of TCP's slow start phase, which exponentially increases the congestion window but requires multiple round-trip times (RTTs) to ramp up.^[62] In web traffic, where many flows transfer fewer than 10 packets, this slow ramp-up can lead to timeouts or incomplete transfers before the connection achieves efficient throughput, as the protocol spends most of its brief lifetime in the initial low-rate phase.^[63] This "mice and elephants" disparity worsens under load, where long flows consume disproportionate resources, starving short ones and increasing their response times.^[62] Mitigations for these short flows include QUIC's 0-RTT resumption, which allows clients to send application data immediately upon connection resumption without waiting for a full handshake, reducing latency for brief interactions like web requests.^[64] In 4G and 5G networks, hybrid congestion detection mechanisms combine loss-based and delay-based signals to better differentiate random errors from true congestion, enabling more adaptive window adjustments and improved utilization in variable radio environments.^[65] These approaches, such as those integrating RTT estimates with packet loss feedback, help avoid overreactions to wireless errors while maintaining fairness.^[66]

Admission Control Approaches

Admission control approaches in network congestion management involve proactively evaluating and limiting new traffic flows to ensure quality of service (QoS) guarantees, such as bounded delay or bandwidth, under varying loads. These methods reject or throttle flows that would exceed resource capacities, thereby preventing congestion from impacting existing sessions. By reserving resources in advance, admission control maintains network stability and prioritizes high-QoS applications like real-time communications. Measurement-based admission control relies on real-time monitoring of network utilization and traffic characteristics to decide on new flow acceptance. A seminal example is the Resource ReSerVation Protocol (RSVP), which enables end-to-end resource reservation for integrated services in IP networks. In RSVP, senders specify traffic specifications (Tspecs) and receivers request QoS via flow specifications (Rspecs) in PATH and RESV messages, respectively. Admission occurs if local resources, such as available bandwidth, suffice after merging reservations using the least upper bound (LUB) operation; otherwise, an error is propagated. This approach admits flows only when measured resources confirm feasibility, supporting controlled-load services with occasional delay violations. Another measurement-based technique uses equivalent token bucket filters derived from observed traffic to approximate flow envelopes. For a new flow with parameters rate r and burst b, admission tests ensure the projected utilization \sum v_j + r < u (where u is the target utilization, typically 90% of link capacity) and delay bounds D_k \geq \frac{b + b'}{u - \sum v_j - r} hold, with measurements updated over sliding windows to reflect actual behavior. Simulations show this achieves high utilization (up to 62% for bursty traffic) while meeting delay guarantees, outperforming parameter-based methods that assume worst-case scenarios. Parameter-based admission control uses declarative flow parameters, such as peak rate and burst size, to estimate resource needs without ongoing measurements, often applied in voice over IP (VoIP) for call admission control (CAC). In VoIP networks, the ITU-T G.107 E-model computes a Transmission Rating Factor (R) from parameters including mouth-to-ear delay, packet loss, and codec type to predict mean opinion score (MOS). A new call is admitted if the projected R-factor exceeds a threshold (e.g., R > 70 for good quality), ensuring the aggregate load maintains acceptable speech quality without real-time probing. This method integrates equipment impairment factors (Ie) and delay impairments (Id) via R = 94.2 - I_e - I_d + A, where A is an advantage factor, allowing CAC to reject calls that would degrade overall network quality below the target. Key algorithms in admission control include token bucket tests for envelope conformance and shadow queues for predictive simulation. Token bucket admission evaluates flows against a regulator with rate \rho and depth \sigma; a flow is admitted if its parameters fit within residual capacity without violating service curves, as formalized in network calculus for worst-case analysis. Shadow queues simulate hypothetical queue buildup in a virtual environment to test admission impacts without perturbing live traffic, enabling proactive rejection of flows that would cause excessive delays. For instance, in wireless multimedia networks, shadow clusters estimate resource availability across base stations by virtually replicating call handoff probabilities, admitting calls only if simulated loads stay below thresholds. These algorithms balance utilization and QoS by modeling transient behaviors. Admission control finds applications in Multiprotocol Label Switching (MPLS) networks and Software-Defined Networking (SDN) to enforce guaranteed service levels. In MPLS, routing-based admission control solves constrained shortest path problems to allocate label-switched paths (LSPs) meeting delay bounds, admitting flows via exact optimization of bandwidth along multi-path routes. In SDN, centralized controllers implement scalable models using pre-established multi-paths, dynamically allocating resources based on global topology views to support QoS-aware flow steering. By preventing overload, these approaches minimize performance degradation, such as reduced throughput or increased latency for admitted flows.

Modern Developments

Congestion in Data Centers and Cloud

Network congestion in data centers and cloud environments arises from the high-density, virtualized nature of these systems, where thousands of servers communicate intensively within the same fabric. Unlike wide-area networks, data center traffic is predominantly east-west, involving inter-server communications that can overwhelm internal links due to bursty, many-to-one patterns. A key pathology is the incast phenomenon, where multiple senders simultaneously transmit to a single receiver, leading to buffer overflow and severe throughput collapse in TCP-based flows. This issue is exacerbated in storage and shuffle phases of big data workloads, causing the receiver's goodput to drop to a small fraction of the link capacity when the number of senders exceeds the bandwidth-delay product.^[67]^[68]^[69] To support low-latency applications like high-performance computing and AI inference, data centers increasingly deploy RDMA over Converged Ethernet (RoCE), which enables direct memory access without CPU involvement but introduces new congestion challenges in lossless Ethernet fabrics. RoCE relies on priority flow control (PFC) to prevent drops, yet this can cause head-of-line blocking and cascaded pauses across switches, amplifying latency during microbursts. In virtualized setups, east-west traffic between virtual machines (VMs) often dominates, accounting for over 70% of total volume in cloud workloads, leading to overload on spine-leaf interconnections as VMs migrate or replicate data across racks.^[70] Fat-tree topologies, common in data centers for their scalability and multipath redundancy, suffer from uneven load distribution in equal-cost multipath (ECMP) routing, where hashed flows can congest specific links, reducing overall bisection bandwidth utilization to below 50% under skewed traffic. Solutions like Hedera address this through dynamic flow scheduling: it monitors elephant flows via switch counters and reallocates them to underutilized paths using heuristics like randomized rounding, improving throughput by 2-3x in multi-stage fabrics without hardware modifications.^[71] For RoCE-specific congestion, Data Center Quantized Congestion Notification (DCQCN) integrates explicit congestion notification (ECN) with rate-based control at endpoints, allowing RDMA senders to react to switch feedback by reducing rates in 512-byte quanta, achieving near-line-rate performance and fairness in Clos networks.^[72] At petabit scales, software-defined networking (SDN) via protocols like OpenFlow enables centralized control for dynamic path provisioning and congestion avoidance, supporting high bisection bandwidths in hyperscale clouds by rerouting flows around hotspots in real-time. The surge in AI training workloads during the 2020s has intensified these demands, with all-reduce operations generating synchronized bursts that saturate inter-GPU links, necessitating specialized congestion controls like message-level signaling to balance collective communications and reduce tail latencies by up to 40%.^[73]

Emerging Techniques in 5G and Beyond

In 5G networks, network slicing enables the creation of logically isolated virtual networks on shared physical infrastructure, each configured to meet specific quality of service (QoS) requirements and thereby preventing congestion spillover between diverse applications such as enhanced mobile broadband and massive machine-type communications. This technique allocates dedicated resources to slices, ensuring predictable performance and reducing interference in multi-tenant environments. For ultra-reliable low-latency communications (URLLC), a key 5G service category, stringent requirements include end-to-end latency below 1 ms and reliability of at least 99.999%, which demand advanced slicing to isolate critical traffic from potential bottlenecks.^[74]^[75] As of 2025, 5G-Advanced (3GPP Release 18) introduces further enhancements for congestion management in URLLC, including integrated AI/ML for predictive resource allocation and improved slicing for dynamic traffic handling.^[76] Machine learning and artificial intelligence are increasingly integrated into 5G congestion management for predictive control, with reinforcement learning algorithms adapting transmission rates dynamically to forecast and avert bottlenecks in variable wireless conditions.^[77] For instance, research on enhancing congestion control protocols like Google's BBR with machine learning-based probing aims to estimate available bandwidth more accurately in 5G scenarios, improving throughput while minimizing latency spikes.^[78] These AI-driven methods outperform traditional reactive approaches by learning from network states in real-time, particularly in heterogeneous 5G deployments.^[79] The QUIC protocol, standardized as RFC 9000, represents a shift in transport-layer design by operating over UDP and embedding congestion control directly into its multipath-capable framework, which enhances resilience to packet loss and reduces head-of-line blocking in congested mobile networks.^[80] QUIC's integration with HTTP/3 further optimizes web traffic in 5G environments by enabling faster connection establishment and seamless multiplexing, alleviating congestion at the application layer.^[80] It includes built-in extensions for explicit congestion notification to signal impending overloads proactively.^[80] Looking toward 6G, terahertz (THz) communications promise ultra-high data rates but introduce congestion challenges due to severe atmospheric absorption, molecular noise, and the need for precise beamforming in dense user scenarios, necessitating novel resource allocation strategies. Recent post-2023 research emphasizes edge computing offloading, where tasks are processed at network edges to bypass core congestion, significantly lowering latency and bandwidth demands in 5G-advanced and 6G architectures.^[81] This approach, often combined with in-network computing, distributes load effectively for delay-sensitive applications.

References

[1]
Congestion Control Principles - » RFC Editor
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 ...<|control11|><|separator|>
[2]
Understanding Network Traffic & Network Congestion - Splunk
Common causes of congestion include increased user demand, limited bandwidth, hardware limitations, inefficient network configurations, and unexpected traffic ...Network Bandwidth & Network... · Network Bandwidth In Cloud... · Estimating Network Bandwidth...
[3]
https://ieeexplore.ieee.org/document/10076206
[4]
[PDF] Congestion control in computer networks: issues and trends
Congestion control allocates network resources to maintain acceptable performance when demand exceeds capacity, including bandwidth, buffer space, and ...
[5]
Network Congestion - an overview | ScienceDirect Topics
Network congestion refers to a situation in a network where a node is overwhelmed with traffic beyond its capacity, leading to delays in queues and loss of ...
[6]
[PDF] Congestion Avoidance and Control - CS 162
To make this concrete, if the network is running at 75% of capacity, as the Arpanet was in last April's collapse, one should expect round-trip-time to vary by a ...Missing: 1980s | Show results with:1980s
[7]
[PDF] Congestion Control in Computer Network
If the processors of routers are slow then queue will build up which again causes congestion. 3. Low bandwidth lines also affect congestion. If the bandwidth of ...
[8]
Traffic Management for High-Speed Networks (1997)
Network congestion will increase as network speed increases. New control methods are needed, especially for handling "bursty" traffic expected in very high ...Missing: primary insufficient inefficiencies<|separator|>
[9]
Unjamming the Information Superhighway and saving the Internet
Dec 5, 2018 · In 1986, the burgeoning Internet was nearly two decades old and had 10,000 users. It was also facing imminent collapse due to network ...
[10]
Computer Networks and Systems: Queueing Theory and ...
From the Publisher: This text, intended for a first course in performance evaluation, is a self-contained treatment covering all aspects of queuing theory.
[11]
RFC 6349: Framework for TCP Throughput Testing
... bits per second) and its end-to-end delay (in seconds). +---+ +----+ +----+ ... Ishac, "Defining Network Capacity", RFC 5136, February 2008. [RFC5357] ...
[12]
RFC 9097: Metrics and Methods for One-Way IP Capacity
... Network Capacity and Maximum IP-Layer Capacity, and the Experimental metric ... bits per second.¶. In addition, the use of the load rate adjustment ...
[13]
A QoE Perspective on Sizing Network Buffers - ACM Digital Library
Traditionally, the size of router buffers is determined by the bandwidth-delay product discipline (normal discipline), which is the product of the link ...
[14]
A Survey on Mechanisms for Fast Network Packet Processing
Network performance is affected by data transmission based on physical link and packet processing handled by operating system.Missing: influencing capacity
[15]
Measured capacity of an Ethernet: myths and reality
There are many factors that influence a choice between different technplogies, including availability, acceptance as a standard, cost per station and per ...
[16]
https://ieeexplore.ieee.org/document/7582516
[17]
Hardware cost and capacity analysis of future TDM- and WDM-PON ...
We developed a Pareto access traffic model to take into account the bandwidth gain reachable through statistical multiplexing of the shared bandwidth for TDM ...
[18]
Capacity-Delay-Error-Boundaries: A Composable Model of Sources ...
In 1962. Kleinrock advanced this theory to prove the resource efficiency of packet-switching, that is achieved by bursty sources due to resource sharing. For ...<|control11|><|separator|>
[19]
Congestion avoidance and control - ACM Digital Library
Congestion control involves finding places that violate conservation and fixing them. By 'conservation of packets' I mean that for a connection 'in equilibrium ...
[20]
[PDF] Analytical methods for network congestion control - Caltech's Netlab
ABSTRACT. The congestion control mechanism has been responsible for maintaining stability as the. Internet scaled up in size, speed, traffic volume, ...
[21]
[PDF] The Macroscopic Behavior of the TCP Congestion Avoidance ...
In this paper, we analyze a performance model for the TCP Congestion Avoidance algorithm. The model pre- dicts the bandwidth of a sustained TCP connection sub- ...Missing: fluid | Show results with:fluid<|control11|><|separator|>
[22]
[PDF] shadow prices, proportional fairness and stability
This paper analyzes rate control algorithms for communication networks, focusing on stability and fairness, and how bandwidth is shared between competing ...
[23]
RFC 2914 - Congestion Control Principles - IETF Datatracker
The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control.
[24]
RFC 2581 - TCP Congestion Control - IETF Datatracker
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.
[25]
ATM Congestion Control
Open-Loop vs Close-Loop. Open-loop approaches do not need end-to-end feedback ... The debate between rate- based and credit-based approach is presented.
[26]
[PDF] On the Effectiveness of Delay-Based Congestion Avoidance
The debate between Loss-based Congestion Avoidance (LCA) and Delay-based Congestion Avoidance (DCA) is almost as old as TCP congestion control itself.
[27]
TCP Vegas: new techniques for congestion detection and avoidance
Vegas is a new TCP implementation achieving 40-70% better throughput and less loss than Reno TCP, using three key techniques.
[28]
RFC 5166 - Metrics for the Evaluation of Congestion Control ...
This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet.Missing: latency | Show results with:latency
[29]
RFC 3290 - An Informal Management Model for Diffserv Routers
1 Leaky Buckets A leaky bucket algorithm is primarily used for shaping traffic as it leaves an interface onto the network (handled under Queues and Schedulers ...
[30]
RFC 2992 - Analysis of an Equal-Cost Multi-Path Algorithm
This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by ...
[31]
Best Practices in Core Network Capacity Planning White Paper - Cisco
To ensure that bursts above the average do not affect the SLAs, the actual bandwidth may need to be overprovisioned relative to the measured average rates.
[32]
RFC 2474 - in the IPv4 and IPv6 Headers - IETF Datatracker
This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the ...Missing: EF AF
[33]
RFC 5681: TCP Congestion Control
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.
[34]
RFC 6298 - Computing TCP's Retransmission Timer
RFC 6298 defines the standard algorithm for TCP senders to compute and manage their retransmission timer, using SRTT and RTTVAR state variables.
[35]
RFC 6582 - The NewReno Modification to TCP's Fast Recovery ...
This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno".
[36]
RFC 9438: CUBIC for Fast and Long-Distance Networks
CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability ...Table of Contents · Design Principles of CUBIC · CUBIC Congestion Control
[37]
RFC 7567 - IETF Recommendations Regarding Active Queue ...
It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices.Missing: bufferbloat | Show results with:bufferbloat
[38]
[PDF] Random Early Detection Gateways for Congestion Avoidance
This paper presents Random Early Detection (RED) gate- ways for congestion avoidance in packet-switched net- works. The gateway detects incipient congestion ...
[39]
RFC 2309 - Recommendations on Queue Management and ...
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.
[40]
Chapter: Configuring Weighted Random Early Detection - Cisco
Mar 17, 2008 · This module describes the tasks for configuring Weighted Random Early Detection (WRED), distributed WRED (DWRED), flow-based WRED, and DiffServ ...Missing: original | Show results with:original
[41]
Dynamics of random early detection - ACM Digital Library
... Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer ...
[42]
https://www.rfc-editor.org/rfc/rfc9438.html
[43]
https://datatracker.ietf.org/doc/html/rfc7567
[44]
https://www.icir.org/floyd/papers/early.twocolumn.pdf
[45]
Data center TCP (DCTCP) - ACM Digital Library
DCTCP leverages Explicit Congestion Notification (ECN) in the network to provide multi-bit feedback to the end hosts. We evaluate DCTCP at 1 and 10Gbps speeds ...
[46]
[PDF] Data Center TCP (DCTCP) - People | MIT CSAIL
Aug 30, 2010 · DCTCP combines Explicit Congestion Notification (ECN) with a novel control scheme at the sources. It extracts multibit feed- back on congestion ...
[47]
RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to ...
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.
[48]
https://datatracker.ietf.org/doc/html/rfc3168#section-5
[49]
RFC 8087 - The Benefits of Using Explicit Congestion Notification ...
ECN benefits include increased throughput, reduced delay, reduced head-of-line blocking, and reduced probability of RTO expiry.
[50]
[PDF] TCP Performance Issues over Wireless Links - UCSD CSE
A prime concern for TCP is congestion. Congestion occurs when routers are overloaded with traffic that causes their queues to build up and eventually overflow, ...
[51]
[PDF] Understanding Congestion in IEEE 802.11b Wireless Networks
As channel utilization increases, a large number of frame errors and retransmissions occur. As retransmissions increase, most network cards decrease the rate at ...
[52]
Forward acknowledgement: refining TCP congestion control
The FACK algorithm is based on first principles of congestion control and is designed to be used with the proposed TCP SACK option. By decoupling congestion ...
[53]
RFC 2018 - TCP Selective Acknowledgment Options
A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations.
[54]
Performance and improvements of TCP CUBIC in low-delay cellular ...
We show that the early transition to Congestion Avoidance results in significant underutilization of the cellular network capacity, particularly for short-lived ...
[55]
[PDF] Improving TCP Slow Start Performance in Wireless Networks with ...
Unfortunately, the typical default TCP implementation often exits slow start too early, before capacity has been reached, causing underutilization, particularly ...
[56]
[PDF] The war between mice and elephants - Network Protocols Ninth ...
Our simulation results show that: (1) in a highly loaded network, pref- erential treatment is necessary to provide short TCP connections with better response ...
[57]
[PDF] Halfback: Running Short Flows Quickly and Safely - acm sigcomm
As TCP's slow-start needs multiple RTTs to detect its fair sending rate, many short flows do not leave this startup phase before finishing transmission. The ...
[58]
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, ...
[59]
A Comprehensive Overview of TCP Congestion Control in 5G ... - NIH
Network congestion is the result of a network node being overwhelmed with more data than it can process. Buffers are added to the communication nodes to prevent ...
[60]
End-to-end congestion control approaches for high throughput and ...
Feb 26, 2021 · In this work, we present end-to-end CCAs that target a high throughput and a low latency over highly variable network links, and classify them ...Missing: budgets | Show results with:budgets
[61]
Understanding TCP incast throughput collapse in datacenter networks
TCP Throughput Collapse, also known as Incast, is a pathological behavior of TCP that results in gross under-utilization of link capacity in certain many-to- ...Missing: problem | Show results with:problem
[62]
[PDF] Understanding TCP Incast and Its Implications for Big Data Workloads
TCP incast is a recently identified network transport pathology that affects many- to-one communication patterns in datacenters . It is caused by a ...
[63]
[PDF] Re-architecting Congestion Management in Lossless Ethernet
To enable RoCE deployment in large-scale. IP-routed data center networks, DCQCN [49] is developed through replacing the congestion notification mechanism de-.
[64]
Improving datacenter performance and robustness with multipath TCP
With MPTCP, this outperforms FatTree for a wide range of workloads, but costs the same. In existing data centers, MPTCP is readily deployable leveraging widely ...
[65]
Hedera: Dynamic Flow Scheduling for Data Center Networks | USENIX
Hedera: Dynamic Flow Scheduling for Data Center Networks, booktitle = 7th USENIX Symposium on Networked Systems Design and Implementation (NSDI 10), year = ...
[66]
[PDF] VFP: A Virtual Switch Platform for Host SDN in the Public Cloud
Mar 27, 2017 · VFP runs on all Azure servers, powering millions of VMs, petabits per second of traffic, and providing load balancing for exabytes of storage, ...
[67]
How the U.S. National Science Foundation Enabled Software ...
Oct 24, 2025 · For our datacenter networks, we built Jupiter to scale out to many petabits per second of bisection bandwidth per datacenter. The key ...
[68]
Congestion Control for AI Workloads with Message-Level Signaling
Aug 6, 2025 · Large-scale AI training is among the most demanding workloads in datacenter networks. The unique characteristics of low flow entropy ...
[69]
5G for the connected World - 3GPP
Nov 13, 2019 · Ultra-high reliability of the connection between device and network means at least 99.999% (three nines!) reliability is needed to keep a ...
[70]
https://www.usenix.org/system/files/nsdi20spring_cheng_prepub_0.pdf
[71]
https://www.usenix.org/conference/nsdi10-0/hedera-dynamic-flow-scheduling-data-center-networks
[72]
[PDF] Machine Learning for End-to-end Congestion Control
2) Congestion Prediction: Congestion prediction plays an important role in dynamic routing, congestion control, con- gestion avoidance, and proactive ...Missing: v2 | Show results with:v2
[73]
Reinforcement Learning based Adaptive Congestion Control for ...
Sep 12, 2025 · A Comprehensive Overview of TCP Congestion Control in 5G Networks: Research Challenges and Future Perspectives ... congestion control and ML.
[74]
RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
To enable ECN, a sending QUIC endpoint first determines whether a path supports ECN ... ECN is rarely disabled for paths that properly support ECN. Any path that ...Table of Contents · Streams · Cryptographic and Transport... · Connection Migration
[75]
Hybrid traffic Offloading method for distributed edge computing in 6G ...
Jul 2, 2025 · This solution will enable drastic reduction of task processing delays and power consumption by the user devices [9-11]. INC is based on network ...Missing: post- | Show results with:post-