Congestion Control

Congestion begins when traffic reaches part of a network faster than that part can carry it for a sustained period. Packets wait in a router's output buffer, called a queue. The bottleneck is the link with the least capacity available to this traffic along its path.

Follow the surplus

Suppose a router receives 12 Mbps for an output link that can send 10 Mbps. It cannot speed up the output to match the input. Each second leaves 2 megabits waiting, or 250,000 bytes after division by 8. Starting empty, a 1,000,000-byte buffer fills in:

A packet joining behind that much queued data waits for the link to transmit the data ahead of it:

Once the buffer stays full, the output still carries only 10 Mbps. About 2 Mbps of the 12 Mbps arriving is dropped, one sixth of the offered traffic. These calculations treat arrivals and departures as steady rates; packet-by-packet timing adds small variations.

Decide whether the queue will drain

A short burst is different from sustained overload. A queue can absorb a burst and drain when arrivals fall below the output rate. If steady arrivals exactly match the output rate, an existing queue persists: each departure is replaced by one arrival. Sustained arrivals above the output rate make the queue grow until the buffer fills.

Real traffic is uneven. Even below full average utilization, bursts make packets wait. Near capacity, there is little spare time to drain those bursts, so average delay rises sharply. Congestion mainly increases the queueing part of packet delay; processing, transmission, and propagation are separate components.

Name the rate you mean

A speed mismatch can expose the bottleneck: a 1 Gbps local network may feed a 50 Mbps access link. Aggregation has the same effect when several router inputs share one output. A single input can look modest while their sum overloads that output.

Choose the right limit

Flow control protects the receiver's buffer using its advertised receive window. Congestion control protects the path between the endpoints. A receiver can have ample free memory while a router on the path drops packets.

A larger router buffer can hold a longer burst, but sustained overload fills any finite buffer and adds waiting time. A faster bottleneck link removes that capacity shortage. Another link then limits the path; it becomes congested only when traffic exceeds the capacity available there.

A full link is useful only when its traffic helps deliver new data. Congestion consumes capacity in ways that can make useful delivery fall even while the network stays busy.

Count the costs

Queueing delay comes first. A video call can become hard to follow before any packets are dropped, because speech arrives too late. Reliability alone cannot repair that delay.

Lost packets create a second cost: a reliable sender retransmits them. If a 10 Mbps link carries equally sized packets and 20% repeat data already carried on that link, at most 8 Mbps carries new data:

Application goodput is lower after accounting for headers and any losses elsewhere. The link's activity therefore overstates the progress made by the application.

Some retransmissions are unnecessary. A packet can be waiting in a long queue when the sender's timer expires. Its replacement then enters the same busy network. Both copies may arrive, but the receiver keeps the data only once. Queueing has converted a delay problem into extra offered load.

Look upstream of a drop

A drop near the destination can waste work at several earlier links. Imagine a packet crossing links A and B before being dropped in the queue for C. The transmissions on A and B used capacity without delivering that packet. Repeating this pattern leaves less upstream capacity for traffic that could have reached its destination.

As offered load rises, throughput initially rises too. With enough downstream drops, however, increasing load sends more traffic into work that will be wasted. End-to-end throughput can peak and then fall. Congestion collapse is the extreme: offered load remains high while useful goodput falls toward zero.

In October 1986, throughput between Lawrence Berkeley Laboratory and UC Berkeley fell from 32 kbps to 40 bps, an 800-fold fall. Jacobson and Karels' 1988 work introduced a coordinated response: slow start, congestion avoidance, better round-trip-time estimation, and exponential timer backoff. Window control and sensible timers address different parts of the feedback loop.

Find the useful operating range

Raj Jain's knee and cliff describe two boundaries. Beyond the knee, added load brings little extra throughput but much more delay. Beyond the cliff, throughput falls as losses and wasted work dominate. Congestion control seeks efficient delivery near the knee while staying clear of collapse.

The Internet has no central controller assigning every sender a rate. Each sender must react to the feedback it sees. If one keeps transmitting at a fixed high rate while others back off, it can take their capacity and deepen the overload.

Retransmission makes a byte stream reliable, but it does not make loss free. Recovery consumes capacity and delays delivery of the missing data; waiting for a retransmission timer can stall the connection much longer than fast recovery does.

A sender does not directly see every router queue on its path. Congestion control is a feedback process: observe delivery, decide what the observations mean, and adjust the amount or rate of traffic entering the network.

Locate the feedback source

In end-to-end control, endpoints infer congestion from loss or delay without an explicit router message. Reno uses loss. Vegas uses changes in round-trip time. BBR builds a path model from delivery-rate and RTT measurements.

In network-assisted control, a router supplies explicit feedback. ECN marks a forward-traveling packet, and the receiver reports the mark in its acknowledgment. Older ATM schemes could report an explicit allowed rate. A router can also send a message directly back to the sender, called a choke packet. The Internet's ICMP Source Quench used that approach and was deprecated in 2012.

Read signals carefully

With drop-tail queues, loss normally arrives after the buffer fills. Active queue management can drop or mark packets earlier. This changes when a signal arrives without changing the sender's need to respond.

Minimum observed RTT is useful because it approximates a path with little queueing. An RTT above that minimum suggests waiting, but an endpoint must interpret measurements over time. Neither one noisy sample nor every lost wireless packet identifies the cause with certainty.

Control a window or a rate

A window-based sender caps unacknowledged data in flight. As acknowledgments return, space opens for new data. A rate-based sender sets a target rate and usually uses pacing, spacing packets over time. The controls are linked:

For example, 100,000 bytes per 50 ms corresponds to 2,000,000 bytes/s, or 16 Mbps, when the window is the active limit. A rate-based controller can also use a window as an upper bound on outstanding data.

Balance several goals

Efficiency means keeping available bottleneck capacity busy. Fairness concerns how competing flows divide it. Low delay requires short queues; stability avoids large, repeated swings; responsiveness means adapting when capacity or competition changes. A rule that quickly fills a path can still be poor at keeping delay low or sharing with other algorithms.

TCP's controller usually runs in the operating system. QUIC's controller usually runs in an application library. UDP supplies no controller, so applications using it must provide congestion control themselves. The carrier protocol does not remove the obligation to respond to congestion.

The congestion window, cwnd, is a sender-side limit on unacknowledged data in flight. It is measured in bytes, though traces often count maximum-size segments. It is not a TCP header field. The receiver advertises a different limit, the receive window, rwnd.

Apply both limits

New transmissions must fit within both flow control and congestion control. The usable limit is:

If cwnd is 30,000 bytes and rwnd is 18,000 bytes, the receiver's limit governs. With 12,000 bytes still outstanding, the sender can send another 6,000 bytes. After a congestion-window reduction, existing data may exceed the new limit; the sender waits for acknowledgments before adding more.

The maximum segment size, MSS, counts application data, excluding headers. A 1,500-byte Ethernet MTU minus 20-byte IPv4 and 20-byte TCP headers leaves 1,460 bytes, with no options. Standards use SMSS for the sender's MSS.

Turn a window into a rate

A window-limited sender delivers roughly one window per RTT. For cwnd of 65,536 bytes and RTT of 50 ms:

Multiply by 8 to obtain about 10.5 Mbps. This estimate also needs enough application data, a receive window at least as large, and a path able to carry the resulting rate.

Fill the path without filling its queue

The bandwidth-delay product, BDP, is bottleneck bandwidth times the queue-free, minimum RTT. For 100 Mbps and 40 ms:

Dividing by 8 gives 500,000 bytes, about 342 segments of 1,460 bytes. One BDP in flight keeps this idealized bottleneck busy with no standing queue. Less data leaves idle capacity; excess data waits and raises measured RTT. Computing BDP from an already inflated RTT mistakes queued data for data the path needs.

ACK clocking helps maintain the pace. As packets leave the bottleneck, ACKs return and release space for replacements. In steady state, departures therefore help time new arrivals. This is the conservation-of-packets idea behind TCP's self-clocking behavior.

Set the starting point and threshold

RFC 5681's initial window ranges from two to four segments according to SMSS: four up to 1,095 bytes, three through 2,190 bytes, and two above that. RFC 6928 allows an initial window up to ten segments. A trace starting at one segment is a useful teaching trace, not a claim that all new connections start there.

ssthresh, the slow-start threshold, selects the growth mode. Below it, TCP uses slow start; above it, congestion avoidance. At equality RFC 5681 permits either. A high initial threshold lets a new sender discover capacity through slow start.

TCP first has to discover how much traffic the path can carry. Slow start expands the window rapidly from a small starting point. Congestion avoidance then probes more cautiously once the slow-start threshold is reached.

Count acknowledgments in slow start

RFC 5681 increases cwnd by up to one SMSS for each acknowledgment of new data:

where N is the newly acknowledged byte count. With one ACK per full segment and enough data to fill each window, every segment sent makes room for two in the next round: one replacement and one from the increased window.

Starting at 1 MSS, the round-by-round values are 1, 2, 4, 8, 16, 32, and 64 MSS. Six RTTs reach 64 MSS. At 100 ms per RTT, that is 0.6 s. The name reflects a safer start than immediately sending a whole receive window; the growth itself is exponential.

Delayed ACKs change the count. If the receiver sends one ACK for every two full segments, the simple per-ACK rule gives roughly 1.5-fold growth per RTT. Appropriate Byte Counting, described in RFC 3465, uses newly acknowledged bytes to address the dependence on ACK frequency.

Switch growth modes

For a trace with initial cwnd of 1 MSS and ssthresh of 8 MSS, choose congestion avoidance at equality. The trace becomes:

The first three changes double the window. Later changes add one MSS per RTT. Loss can interrupt either phase. Implementations using HyStart++ (RFC 9406) can also leave slow start early when delay rises.

Explain additive increase

A common per-ACK rule during congestion avoidance is:

At 10 MSS, one ACK adds about 0.1 MSS. About ten ACKs arrive over the round, so the total increase is about one MSS. The per-ACK increment becomes smaller as cwnd grows, keeping the round-by-round increase roughly constant.

This difference matters on a large path. From 16 to 32 MSS takes one RTT in ideal slow start but sixteen RTTs in congestion avoidance. The slower growth reduces sudden overshoot once the sender has a useful estimate of capacity.

Recognize a restart

Slow start is not limited to the beginning of a connection. A retransmission timeout resets cwnd to one segment. An idle period longer than the retransmission timeout also requires a restart from no more than the initial window, because the earlier ACK clock and capacity estimate may no longer fit the path.

Congestion avoidance does not hold cwnd at a fixed safe value. It keeps adding capacity until congestion feedback arrives. On a drop-tail path, this continued probing tends to build a standing queue before loss signals the sender to back off.

TCP can infer a missing segment from a timer or from duplicate acknowledgments. The distinction matters: a timeout gives less evidence that the network is still delivering traffic than three duplicate ACKs do.

Set the new threshold

Reno uses the amount actually outstanding, FlightSize, to set:

FlightSize is often close to cwnd during a fully active transfer, but they need not be equal when the application sends little data. The lower bound prevents the threshold from falling below two segments.

After a timeout, the sender retransmits, sets cwnd to one SMSS, and restarts slow start. Repeated timeouts for the same data double the retransmission timer. This exponential backoff prevents persistent failure from producing an equally persistent stream of retries.

Recover before the timer expires

Three duplicate ACKs show that three later segments arrived beyond a gap. They do not mean three segments were lost. One or two duplicates can arise from reordering, so TCP waits for the third before fast retransmit sends the missing segment.

Reno then enters fast recovery. Suppose FlightSize is 12 MSS. The new threshold is 6 MSS, and Reno temporarily sets:

The three extra segments account for packets evidenced as having left the network. Each further duplicate ACK inflates cwnd by one MSS, allowing continued sending when the window permits. When an ACK advances the cumulative acknowledgment, Reno deflates cwnd to 6 MSS and resumes congestion avoidance.

With an initial window of 1 MSS and ssthresh of 8 MSS, cwnd grows 1, 2, 4, 8, 9, 10, 11, 12 MSS before the loss. Reno eventually continues at 6, 7, 8, 9. Tahoe restarts at 1, 2, 4, reaches the new threshold of 6, then continues 7, 8.

Repair several holes in one window

Classic Reno exits recovery at the first ACK of new data. If that ACK covers only part of the original flight, another gap remains. Reno can reduce again or time out.

NewReno (RFC 6582) stays in recovery on such a partial ACK and retransmits the next missing segment. It leaves when all data outstanding at recovery entry is acknowledged. SACK reports received blocks explicitly; SACK-based recovery can identify and repair several holes within a round trip.

One congestion episode should normally cause one reduction, even if several packets are lost. NewReno and SACK-based recovery handle this more reliably than classic Reno. CUBIC uses a different reduction factor for ordinary congestion signals, keeping 70%, but also restarts at one segment after a timeout.

Classic Reno repeatedly increases its window and cuts it after congestion. The resulting sawtooth gives a useful steady-state estimate when RTT is roughly constant, fast retransmit detects losses, and timeouts and slow start are absent.

Average the window

Let the peak window be W segments. A halving produces a range from W/2 to W, whose average is 0.75 W. Multiply by MSS to obtain bytes per round trip, then divide by RTT:

For W of 24 segments, MSS of 1,460 bytes, and RTT of 80 ms, the peak rate is 3.504 Mbps. The average is about 2.63 Mbps. Remember that a window in segments needs a segment-size factor; a window already in bytes does not.

Connect throughput to loss

The Mathis approximation expresses the same Reno-like behavior using the loss fraction L:

If MSS is in bytes and RTT in seconds, T is bytes/s. With MSS of 1,460 bytes, RTT of 0.1 s, and loss fraction 0.0001, the denominator is 0.001 s. The result is 1,781,200 bytes/s, about 14.25 Mbps after multiplying by 8.

At a fixed loss fraction, doubling RTT halves throughput. At fixed RTT, doubling throughput requires loss to fall to one quarter, because the denominator contains the square root of loss. A loss fraction of 0.0001 means 0.01%, not 0.0001%.

See the high-speed problem

A 10 Gbps path with a 100 ms queue-free RTT needs 1 billion bits, or 125,000,000 bytes, in flight to fill it. Using 1,500-byte segments gives about 83,333 segments. Halving that window leaves about 41,667 segments to regain. Reno adds one per RTT, so regaining them takes about 4,167 s, nearly 70 minutes.

That 83,333-segment value is the window needed to send at 10 Gbps at one instant. A Reno sawtooth averaging 10 Gbps would need a higher peak because its average window is only three quarters of its peak. The loss-rate formula estimates that sustaining a 10 Gbps average with this MSS and RTT requires loss around one segment in 4.7 billion.

Check other limits

A controller cannot deliver faster than the bottleneck, and a small receive window can bind before cwnd does. Use the smallest applicable limit. Timeouts reduce the rate below the simple model, and a short object may finish entirely in slow start. Its completion time depends strongly on startup rounds and the initial window, so the long-lived formula is a poor description of that transfer.

A faster access link therefore helps only when it removes an active limit. Long RTT, loss, or a small window can leave a single connection far below the upgraded link's capacity.

If K active flows all want more capacity than a bottleneck can give them, an equal per-flow share is R/K, where R is the available rate. Efficiency asks whether their rates add to R. Fairness asks how evenly they divide it.

Put two rates on a diagram

In a Chiu–Jain diagram, the horizontal and vertical coordinates are the two flow rates. The efficiency line is:

The fairness line is the diagonal where the rates are equal. Their intersection is the fair, fully used allocation. On a 10 Mbps link it is 5 Mbps per flow. Points below the efficiency line leave capacity unused; points above it offer more traffic than the link can carry.

Separate the two updates

Additive increase adds the same amount to each rate. Starting from 8 and 1 Mbps, adding 0.5 Mbps to each gives 8.5 and 1.5 Mbps. The difference remains 7 Mbps, but the smaller flow gains more relative to its starting rate. On the diagram the point moves parallel to the equality diagonal.

Multiplicative decrease multiplies both rates by the same factor. Halving 9 and 2 Mbps produces 4.5 and 1 Mbps. Their ratio is unchanged, while the absolute difference falls from 7 to 3.5 Mbps. The point moves toward the origin and quickly removes overload.

These are different meanings of improvement: equal addition improves the relative balance; proportional reduction shrinks the absolute gap. Repeating the two prevents the gap from growing back while capacity is probed again.

Trace several cycles

Start at 8 and 1 Mbps on the 10 Mbps link. Add 0.5 Mbps per flow per step and reduce only after the total exceeds capacity. After two increases the rates are 9 and 2, totaling 11. Halving gives 4.5 and 1.

Five more increases reach 7 and 3.5, totaling 10.5. Halving gives 3.5 and 1.75. The gaps have been 7, 3.5, and 1.75 Mbps. Another synchronized halving makes the next gap 0.875 Mbps. The flows approach equal shares while their total continues to oscillate around available capacity.

Compare other update rules

This convergence assumes equal RTTs, synchronized congestion feedback, matching responses, and flows that stay active long enough. Reno's additive step is about one MSS per RTT and its decrease factor is one half. Other positive additive steps and decrease factors between zero and one give the same basic convergence argument. Real flows need not meet all its assumptions, so an instantaneous unequal pair does not by itself show failure of AIMD.

Equal shares are a useful reference, but real flows can differ in demand, RTT, number of connections, and congestion controller. A fairness claim needs a clear answer to “fair between which flows?”

Calculate Jain's index

For nonnegative flow rates with a nonzero total, Jain's index is:

Rates of 8 and 2 Mbps give a sum of 10 and a sum of squares of 68, so the index is about 0.735. Equal rates give 1. If one of n flows receives everything, the index is 1/n.

The index measures equality, not utilization. Two flows at 1 Mbps each and two at 5 Mbps each both have an index of 1, even though they use different amounts of a 10 Mbps link. Check the total rate separately.

Account for limited demand

Max-min fairness gives low-demand flows what they need, then shares the remaining capacity among flows still seeking more. On a 12 Mbps link, three flows want 2, 8, and 10 Mbps. The initial equal share is 4 Mbps. The first needs only 2, leaving 10 Mbps for the other two. The allocation is therefore 2, 5, and 5 Mbps.

Increasing one of the larger rates would require reducing a flow already at an equal or smaller rate. That property defines max-min fairness. Its unequal allocation can be appropriate even though Jain's equality measure falls below 1.

Identify advantages between flows

Reno grows once per RTT. At the same loss fraction, its approximate throughput is inversely proportional to RTT: a 20 ms flow can achieve about four times the rate of an 80 ms flow. Equal bottleneck access does not erase that timing advantage.

Sharing is also per connection. With nine existing connections, an application adding one might receive about one tenth of the link. If it instead adds eleven comparable connections, its share becomes eleven twentieths, or 55%. HTTP/2 and HTTP/3 multiplex many requests over a connection, while HTTP/1.1 clients often open several connections.

A fixed-rate UDP application may keep sending while TCP flows back off. UDP itself supplies no controller; RFC 8085 calls for applications to add suitable congestion control. A TCP-friendly flow uses no more bandwidth than comparable TCP traffic under the same conditions. TFRC uses the TCP throughput equation to support a smoother rate.

Consider the queue and the algorithm

A FIFO queue does not enforce equal flow shares. Its outcome depends on sender behavior. Fair queuing, including the per-flow scheduling in FQ-CoDel, gives flows separate queues and service opportunities.

CUBIC's growth and Reno's growth differ on large-BDP paths. BBR's sharing with CUBIC also depends on version and buffer depth; early BBR could be aggressive with shallow buffers. No single equality calculation establishes that different controllers will coexist evenly on every path.

A drop-tail queue accepts packets until its buffer is full, then drops new arrivals. Loss-based senders keep probing upward until they receive a congestion signal. With a large drop-tail buffer, that signal can arrive only after a long queue has formed.

Calculate the delay hidden in a buffer

A 2,000,000-byte buffer ahead of a 20 Mbps uplink holds 16 million bits. If it is full, a packet behind that data waits:

An upload can therefore keep throughput high while adding almost a second to a call sharing the uplink. Bufferbloat means persistent excess delay caused by large buffers and the traffic behavior that keeps them occupied.

Buffering still has a purpose: short bursts need somewhere to wait. In the simple single-Reno-flow model, about one BDP of buffering can keep the link busy immediately after a window halving. Making the buffer far larger adds waiting without increasing the link's transmission rate.

Signal congestion before overflow

Active queue management, AQM, drops or marks packets early to signal that senders should reduce their load. A physical overflow is no longer the only way to announce congestion. RFC 7567 recommends widespread AQM deployment.

Random Early Detection, RED, watches a moving average of queue length. Below a minimum threshold it does not signal. Between two thresholds, it drops or marks with an increasing probability. Above the maximum threshold, it signals on every arrival. Averaging prevents a single short burst from looking like persistent overload, but choosing thresholds that work across different speeds and loads is difficult.

Measure waiting time directly

CoDel, Controlled Delay, measures a packet's sojourn time: its time inside the queue. Its standard target is 5 ms and its interval is 100 ms. If even the minimum observed sojourn time stays above target for an interval, a standing queue exists. CoDel then drops or ECN-marks packets, increasing the signaling frequency while the excess delay persists.

The minimum over an interval matters. A burst may produce high delay briefly yet drain soon afterward; a queue whose delay never gets small needs intervention. CoDel's delay measurement lets its defaults work across a wide range of link rates.

FQ-CoDel combines separate flow queues with CoDel. The flow separation helps a large transfer avoid placing every small interactive packet behind its backlog.

Early signals can also reduce global synchronization, where many flows lose packets together, halve together, and leave the link temporarily underused. Randomized early signals spread reactions across time. With ECN-capable traffic, an AQM can send its warning through a mark while still delivering the packet.

Explicit congestion notification, ECN, lets a router deliver a packet and warn that congestion is developing. The mark changes the sender's behavior without creating missing data that must be retransmitted.

Read the IP codepoint

The ECN field is two bits in the IPv4 Type of Service byte or IPv6 Traffic Class.

In the classic RFC 3168 TCP handshake, the client's SYN sets ECE and CWR. An accepting server's SYN-ACK sets ECE. After negotiation, classic TCP marks data packets ECT(0).

Trace the feedback loop

An AQM that would drop an ECN-capable packet as a congestion warning can change its codepoint to CE and forward it. A Not-ECT packet cannot carry that warning and is dropped when the AQM needs to signal. A completely full buffer still drops packets, including ECN-capable ones.

The receiver echoes CE by setting ECE, ECN-Echo, in its ACKs. It continues until it receives CWR, Congestion Window Reduced, from the sender. These flags report and acknowledge the feedback; their presence does not mean data was lost.

For classic Reno-style ECN, start with cwnd of 20 MSS. After ECE arrives, the sender reduces cwnd to 10 MSS and puts CWR on its next new data segment. The receiver stops echoing once CWR arrives. Repeated echoes from the same window do not require repeated halvings. The warning returns on the acknowledgment path, so the response is subject to feedback delay.

ECN specifies the signal; the congestion algorithm supplies the reduction rule. Reno halves, while CUBIC normally retains 70% on an ECN event. Both endpoints and a marking bottleneck must support ECN for this loop to work.

Use the fraction of marks

DCTCP, Data Center TCP, uses frequent marks in a controlled environment. It estimates the marked-byte fraction with a smoothed value alpha:

where M is the recently marked fraction. Some implementations use g of 1/16. It reduces the window using:

With alpha of 0.2, a window of 100 becomes 90; with alpha of 1 it halves. DCTCP needs compatible marking and feedback. Mixing it with classic TCP in one ordinary queue can produce unfair shares.

L4S, the experimental architecture in RFCs 9330–9332, carries a related scalable response onto Internet paths. ECT(1) identifies scalable traffic, and a dual-queue coupled AQM separates it from classic traffic while coordinating their treatment. Frequent shallow marks aim for queueing delay around a millisecond. ECT(1) alone is not a guarantee of that delay: the controller and bottleneck behavior complete the design.

CUBIC addresses Reno's slow growth on fast, long-distance paths. Its window follows elapsed time since a congestion reduction, giving it a different response from a fixed one-segment increase every RTT. RFC 9438 specifies CUBIC; it is the default in major Linux, Windows, and Apple TCP stacks.

Remember the last congestion point

At an ordinary loss or ECN congestion event, CUBIC records its window as Wmax. With a fully used window, its decrease factor of 0.7 retains 70% of the flight size. Reno would retain half. A retransmission timeout is different: CUBIC follows Reno back to a one-segment window and slow start, while setting its threshold with CUBIC's decrease factor.

For the basic cubic epoch after a reduction, the target window in segments is:

Time t is in seconds. When the reduced window is 0.7 Wmax, the return time to the old peak is:

Work through the curve

With Wmax of 100 segments, the reduced window is 70. The value inside the cube root is 75, so K is about 4.22 s. At one second, the curve is about 86.7 segments; at two seconds it is 95.6; at three seconds it is 99.3. It reaches 100 at K.

Below the old peak, growth is initially fast and then slows. This concave region cautiously approaches a point where congestion previously occurred. Near the peak is a relatively flat plateau. Above it, the convex region accelerates to probe for capacity that may now be available. At seven seconds the example curve reaches about 108.6 segments.

Explain the RTT advantage and its limit

Reno needs 50 RTTs to climb from 50 back to 100 segments: 5 s with a 100 ms RTT and 10 s with a 200 ms RTT. The cubic curve's return time depends on the recorded peak and elapsed time, so its 4.22 s return does not depend directly on the ACK count.

CUBIC also computes a Reno-friendly estimate. It uses an equivalent AIMD increase of about 0.53 segments per RTT with a decrease factor of 0.7, taking this estimate when it exceeds the cubic target. Short-RTT paths can therefore recover sooner than the pure cubic return time. Time-based growth reduces a major source of RTT bias; it does not make every real allocation RTT-independent.

Adjust the remembered peak

If congestion recurs below the previous peak, CUBIC's fast convergence lowers the remembered Wmax. A new event at 90 segments after a previous peak of 100 gives:

The immediate reduced window is 63 segments. The remembered peak and the new current window have different jobs: one shapes future growth, while the other limits current sending.

CUBIC remains loss-based, with ECN as an alternative signal. It can build a standing queue on a drop-tail path. Faster recovery and a gentler ordinary reduction improve use of large-BDP paths, but neither by itself guarantees low queueing delay.

Loss is not the only sign of a crowded path. Delay can reveal queued data, while delivery measurements can estimate how much bandwidth the path supplies. Vegas and BBR use these observations in different ways.

Estimate Vegas's queued data

Vegas compares an expected rate based on the minimum, base RTT with the actual rate based on the measured RTT. Their difference, multiplied by base RTT, estimates the flow's queued data.

With cwnd of 50 segments, base RTT of 40 ms, and measured RTT of 50 ms, expected delivery is 1,250 segments/s and actual delivery is 1,000 segments/s. The queue estimate is:

Vegas grows below a lower threshold and shrinks above an upper threshold. If loss-based traffic keeps filling their shared queue, Vegas repeatedly sees delay and backs off, which can leave it a small share.

Build BBR's two-part model

BBR, Bottleneck Bandwidth and Round-trip propagation time, estimates bottleneck bandwidth from recent maximum delivery rates and minimum RTT over a 10 s filter. Their product estimates BDP. Its ideal target is a full link with roughly one BDP in flight and little queued data.

A 50 Mbps bandwidth estimate and 30 ms minimum RTT give 1.5 million bits, or 187,500 bytes, per BDP. A typical congestion-window gain of 2 caps outstanding data around 375,000 bytes. The pacing rate is a separate control: pacing gain times estimated bandwidth. A cap permits data in flight; it does not require the sender to send at twice the bandwidth.

Follow BBR version 3's states

Startup's growth test is less than 25% delivery-rate growth for three rounds. ProbeRTT is scheduled no more often than about every 5 s. On the example path, ProbeBW Up targets 62.5 Mbps and Down 45 Mbps. These version 3 details are specified in the BBR Internet-Draft, not in a published BBR RFC.

Compare feedback and trade-offs

Reno and CUBIC increase until loss or ECN signals congestion. BBR paces from a bandwidth-and-RTT model. It deliberately queues briefly in Startup and ProbeBW Up, so “model-based” does not mean “never builds a queue.”

BBR version 1 largely ignored loss. Version 3 uses heavy loss, around 2% in a round, to constrain overshoot and improve coexistence. It can sustain more throughput on randomly lossy long paths, but cannot perfectly identify why a packet was lost. Its specific ECN response remains open in the draft; any connection declaring ECN support must respond to CE as congestion. Buffer depth, RTT, version, and competing algorithms still matter to fairness.

A protocol ossifies when deployed devices depend on its existing form so strongly that changes become hard to deploy. Middleboxes inspect TCP headers and may reject unfamiliar options or flags. Kernel-based implementations also spread new behavior through operating system updates, often slowly.

Identify the costs QUIC addresses

TCP has evolved through SACK, ECN, window scaling, and new congestion controllers. Yet its structure still matters for web traffic. A conventional new TCP-plus-TLS connection needs the TCP handshake before its TLS handshake. Its single ordered byte stream also means one missing segment blocks delivery of later bytes, including data for unrelated requests. This is transport head-of-line blocking.

A connection's addresses and ports can create another obstacle when a device moves between networks. QUIC, standardized in RFC 9000, changes these parts of transport design while carrying its packets over UDP. HTTP/3 runs over QUIC.

Combine the handshakes

QUIC integrates TLS 1.3 with its transport handshake. In a simple exchange with 80 ms RTT, negligible processing, and no loss, a new TCP-plus-TLS 1.3 connection sends the request after two RTTs and receives the first response bytes after three: 240 ms. A new QUIC connection can receive them after two RTTs: 160 ms.

A resumed QUIC connection may send early application data in its first flight, called 0-RTT. The first response can then arrive after one RTT, 80 ms in this example. Early data can be replayed, so applications restrict it to actions safe to repeat. The term 0-RTT describes when sending can begin, not an instantaneous response.

Separate streams, not all shared limits

QUIC carries independent ordered byte streams. If a packet contains data for image 1, losing it does not block delivery of already received data for images 2 and 3 in separate streams. A packet carrying several streams can affect each one it carried. All streams still share the connection's congestion controller, so loss can reduce their total available rate.

QUIC provides reliable stream delivery on top of UDP. It also provides flow control both per stream and per connection. UDP is the carrier, not a substitute for these transport functions.

Protect changeable details

QUIC encrypts packet payloads, including all transport frames. Header protection covers packet numbers and some first-byte bits. Fields needed for routing and negotiation, such as connection IDs and the version, remain visible. Hiding changeable transport details gives middleboxes less behavior to depend on.

Connection IDs identify a connection independently of the current IP addresses and ports. With path validation, a connection can migrate as a phone moves from Wi-Fi to cellular access, without starting a completely new connection.

QUIC is usually a user-space library. An application update can therefore ship a transport improvement without waiting for every operating system kernel to change. That flexibility also gives the application responsibility for correct loss detection, security, flow control, and congestion control.

QUIC improves what a sender can learn from acknowledgments, but still has to avoid overloading the path. RFC 9002 defines loss detection and a default NewReno-like controller. Implementations can use other suitable algorithms, including CUBIC or BBR.

Identify each transmission

Packet numbers increase and never repeat within a packet number space. Resent data travels in frames inside a new packet with a new number. An ACK can therefore identify the transmission that arrived, avoiding TCP's ambiguity between an original segment and its retransmission.

ACK frames report received ranges and the receiver's ACK delay. After the handshake, the sender uses validated, bounded ACK delay when adjusting RTT estimates; it does not blindly subtract arbitrary receiver delay from every sample.

QUIC declares a packet lost when a packet at least three packet numbers later has been acknowledged, or through its time threshold once a later packet is acknowledged. The recommended time threshold is 9/8 of the larger of the latest and smoothed RTT. A probe timeout, PTO, sends acknowledgment-eliciting probes. PTO expiration alone does not collapse cwnd.

Set byte-based window limits

For maximum datagram size d, RFC 9002's initial window is:

With d of 1,200 bytes, the result is 12,000 bytes. With d of 1,500 bytes, it is 14,720 bytes. The minimum congestion window is two maximum-size datagrams, so those paths have minima of 2,400 and 3,000 bytes respectively.

In the default controller, a loss or new CE congestion signal halves cwnd, bounded below by the minimum, and sets ssthresh to the reduced window. A recovery period prevents another reduction for further losses of packets sent before recovery began. An acknowledgment of a packet sent during recovery ends the period. The sender then resumes normal growth.

Recognize sustained failure

Persistent congestion is stronger evidence than one timer expiration. It requires a sufficiently long run of lost acknowledgment-eliciting packets, with no intervening packet acknowledged and a prior RTT sample. Its duration threshold is:

With 100 ms smoothed RTT, 10 ms variation, 25 ms maximum ACK delay, and negligible timer granularity, the threshold is 495 ms. The qualifying loss interval must exceed that value. The controller then drops cwnd to two datagrams, its minimum window.

Keep feedback and timing useful

QUIC ACKs can report cumulative ECT(0), ECT(1), and CE counts. After validating ECN operation on the path, the sender treats a new CE increase as a congestion event without needing packet loss.

Pacing spreads transmissions. A rate around 1.25 times cwnd divided by smoothed RTT is one suggested approach; burst limits can serve the same purpose. Sending a whole window at once creates a burst even when the average rate is acceptable. User-space deployment makes new controllers easier to ship, but each stack must still share bandwidth responsibly.