How to Learn Network Congestion-Control Algorithms: AIMD, Reno, CUBIC, ECN, BBR and L4S

Wait, What?

A fast sender can make a network slower by sending more.

Congestion control is the family of algorithms that decides how much data a sender should place into a network when the path’s available capacity is unknown and shared with other traffic. At beginner level, the learner watches a congestion window grow and shrink. At professional level, the same problem involves feedback delay, queue dynamics, packet loss, Explicit Congestion Notification, pacing, fairness, round-trip-time bias, active queue management, model-based control, multipath effects and the challenge of evolving the Internet without breaking coexistence.

The central idea is feedback. A sender cannot simply ask the path for a perfect capacity number. It sends, observes signals returned later, updates its belief about safe sending, and repeats. That makes congestion control a beautiful bridge between algorithms, networks and control systems.

Quick Answer

Learn congestion control through the route bottleneck capacity → packets in flight → acknowledgements → round-trip time → congestion window → slow start → additive increase/multiplicative decrease → loss signals → fast retransmit/recovery → Reno/NewReno → CUBIC → pacing → ECN → DCTCP → model-based BBR → QUIC congestion control → active queue management → L4S → fairness, coexistence and production measurement. A beginner should be able to trace a window after ACKs and losses. A professional should be able to explain what signal a controller uses, what state it estimates, how quickly it responds, and what happens when competing controllers share the same bottleneck.

1. Start With a Bottleneck

Imagine a sender connected through several links. The slowest relevant link, or another constrained resource along the path, determines how quickly data can pass. If packets arrive at that bottleneck faster than they depart, a queue grows. If the queue fills, packets are dropped. Even before drops, long queues can create large delays.

Congestion control is therefore not merely about preventing packet loss. It is about finding an efficient operating point while sharing capacity and avoiding destructive queues.

2. Separate Flow Control From Congestion Control

Flow control protects the receiver from being sent data faster than it can accept. Congestion control protects the network path from excessive in-flight traffic. In TCP, the usable sending window is constrained by both receiver and congestion-control state. Confusing these mechanisms hides which resource is actually applying pressure.

3. Learn the Congestion Window as a Budget

The congestion window, usually written cwnd, is a sender-side limit on how much data may be outstanding without acknowledgement. Treat it as a dynamic budget. ACKs return budget; congestion signals cause the controller to revise how large that budget should be.

Before studying formulas, give a learner a window of four segments and ask which segments may be sent, which remain in flight, and how an ACK permits another transmission. The window becomes concrete before it becomes mathematical.

4. Round-Trip Time Makes Feedback Late

A sender acts now but learns the consequences roughly one round trip later. If it increases traffic too aggressively, many packets may already be in flight before congestion becomes visible. This feedback delay is fundamental: congestion control must operate using delayed, noisy evidence about a changing path.

5. Slow Start Learns Capacity Aggressively

Classic TCP starts cautiously, then increases the congestion window rapidly as acknowledgements arrive. The name “slow start” can be misleading to beginners because the growth is deliberately fast relative to additive congestion avoidance. The goal is to discover usable capacity without beginning with an enormous burst.

The standard TCP algorithms—slow start, congestion avoidance, fast retransmit and fast recovery—are specified in RFC 5681.

6. AIMD Is the Classic Shape of Cautious Sharing

Additive Increase, Multiplicative Decrease describes a powerful feedback pattern: while the path appears uncongested, increase the sending window gradually; when congestion is inferred, reduce it by a fraction. The increase probes for more capacity. The multiplicative cut backs away quickly enough to relieve pressure.

Trace two competing flows with equal round-trip times. Ask learners to update each window over several rounds and mark where congestion occurs. The exercise shows that congestion control is partly about coexistence, not just one sender’s speed.

7. Loss Is a Signal, But Not a Perfect One

Traditional TCP often interprets packet loss as evidence that a path has become congested. That is reasonable in many wired networks, but loss can have other causes, and waiting for a full queue to overflow may create unnecessary latency. Modern controllers therefore use richer combinations of loss, delay, explicit marking and model estimates.

8. Duplicate ACKs Can Reveal a Missing Segment Early

When later data arrives but one segment is missing, repeated acknowledgements can indicate a likely loss before the retransmission timer expires. Fast retransmit uses this evidence to retransmit sooner. Fast recovery then avoids collapsing all the way back to initial startup behaviour after every isolated loss.

9. Reno and NewReno Are Important Reference Points

Reno-style congestion avoidance is the conceptual baseline for many courses: grow gradually, reduce on congestion, and use duplicate acknowledgements for fast recovery. NewReno refines recovery when multiple packets are lost from one window. See RFC 6582 for the NewReno modification and RFC 6675 for SACK-based loss recovery.

10. CUBIC Changes the Window-Growth Geometry

CUBIC was designed to scale better on high-bandwidth, high-delay paths than classic Reno growth. Instead of making the congestion window primarily a linear function of acknowledgement count, CUBIC uses a cubic function of elapsed time since the last congestion event, growing carefully around the previous window maximum and more aggressively farther away from it.

CUBIC is standardized in RFC 9438, published in August 2023. Its specification also discusses Reno-friendly behaviour and how the algorithm should coexist with other traffic.

11. A Congestion Window Does Not Specify Packet Timing

Two senders can have the same allowed in-flight volume but transmit it differently. One may release a burst, while another paces packets across the round trip. Pacing can reduce microbursts and produce smoother queue behaviour. This is a systems lesson: an algorithm’s aggregate budget and the schedule used to spend that budget are separate design choices.

12. ECN Lets Routers Mark Congestion Before Dropping

Explicit Congestion Notification allows capable network devices to mark packets instead of relying only on drops to signal incipient congestion. Endpoints then echo the congestion information so the sender can respond. The classic ECN mechanism is defined in RFC 3168.

The teaching distinction matters: the network provides a signal; the congestion-control algorithm decides how to react to that signal.

13. DCTCP Uses the Fraction of Marked Traffic

Data Center TCP, or DCTCP, uses ECN marking in a controlled data-centre environment and estimates how much traffic experienced congestion marking. Rather than treating every congestion event as an identical binary signal, it adjusts the response according to the fraction marked. See RFC 8257.

This is a useful transition from “loss happened” toward richer feedback about congestion severity.

14. BBR Starts From a Different Question

BBR is a model-based congestion-control family developed around estimating bottleneck bandwidth and round-trip propagation time. Instead of making packet loss the primary definition of congestion, it attempts to operate from a model of the path’s delivery characteristics and controls sending using pacing and in-flight limits.

For the conceptual starting point, see Google’s research publication BBR: Congestion-Based Congestion Control. A professional learner should study BBR as a distinct control philosophy, then investigate version-specific behaviour rather than assuming every implementation called “BBR” is identical.

15. QUIC Carries Congestion Control Above UDP

QUIC runs over UDP but still needs reliable delivery and congestion control. RFC 9002 specifies QUIC loss detection and a congestion controller that is broadly NewReno-like while allowing alternative controllers. This is useful professionally because it separates the transport’s packet-number and acknowledgement machinery from the choice of congestion-control algorithm.

16. Queue Delay Can Be Harmful Even When Throughput Is High

A path can deliver lots of data while keeping packets in very long queues. Interactive applications then experience poor latency even though throughput graphs look healthy. This is the bufferbloat problem in practical form: maximizing queue occupancy is not the same as maximizing useful performance.

Teach learners to plot both throughput and latency. One metric cannot stand in for the other.

17. Active Queue Management Changes the Feedback Environment

Routers do not have to wait until a queue is completely full. Active Queue Management can drop or mark selected traffic earlier to signal congestion and control queue delay. Congestion control and queue management therefore form a feedback loop across different machines: endpoint behaviour changes queue behaviour, which changes the signals returned to endpoints.

18. L4S Targets Low Latency With Scalable Feedback

The IETF’s Low Latency, Low Loss, Scalable Throughput architecture, or L4S, combines scalable congestion-control behaviour with more frequent ECN-based feedback and a dual-queue approach designed for coexistence with classic traffic. The architecture is defined in RFC 9330, with the DualQ Coupled AQM in RFC 9332.

The professional lesson is that a new congestion controller cannot be judged in isolation. It must coexist with deployed senders, receivers, queues and middleboxes.

19. Fairness Has More Than One Definition

Equal throughput per flow is one fairness goal, but not the only one. Flows have different RTTs, packet sizes, application needs, priorities and path constraints. Some controllers may be more aggressive under particular conditions. A serious evaluation therefore states the fairness objective rather than reporting a single “fairness score” without context.

20. RTT Bias Is a Feedback-Timing Problem

A flow with a shorter round-trip time receives feedback more frequently than one with a long RTT. Depending on the controller, that can affect how quickly its window grows or how it competes for capacity. RTT is therefore not merely a latency measurement; it can be an algorithmic input that changes the control loop’s dynamics.

21. Professional Evaluation Needs Multiple Axes

• throughput and goodput;
• queueing delay and tail latency;
• packet loss and ECN marking;
• time to utilize newly available capacity;
• reaction to sudden capacity reduction;
• fairness among similar flows;
• coexistence with different congestion controllers;
• behaviour across RTT ranges;
• short-flow completion time versus long-flow efficiency;
• wireless or non-congestion loss sensitivity;
• burstiness and pacing behaviour;
• recovery after idle periods, route changes and transient outages.

No single friendly speed test proves a congestion controller is good. The workload and competing traffic shape the answer.

22. Common Learning Failure States

• Confusing receiver flow control with network congestion control.
• Thinking cwnd is a sending rate rather than an in-flight budget.
• Memorising “slow start doubles” without tracing ACK-driven growth.
• Assuming every packet loss is caused by congestion.
• Treating Reno, CUBIC and BBR as parameter tweaks of one identical algorithm.
• Ignoring packet pacing while discussing only window size.
• Believing ECN itself is a congestion-control algorithm.
• Measuring throughput but not queueing delay.
• Testing one flow alone and making claims about fairness.
• Ignoring RTT when comparing controllers.
• Assuming an Internet-wide mechanism can be deployed without coexistence constraints.
• Quoting one implementation’s behaviour as if it defines an entire algorithm family.

23. A Beginner-to-Professional Learning Ladder

• Level 1: draw a bottleneck queue and explain why it grows.
• Level 2: trace packets in flight under a fixed congestion window.
• Level 3: simulate slow start and AIMD on paper.
• Level 4: implement a toy Reno-style window controller in a simulator.
• Level 5: compare timeout, duplicate-ACK and ECN signals.
• Level 6: study CUBIC’s time-based growth and pacing.
• Level 7: model queue delay and active queue management.
• Level 8: compare loss-based, ECN-sensitive and model-based controllers.
• Level 9: run controlled coexistence experiments across RTTs and bottleneck capacities.
• Level 10: evaluate a production transport using throughput, latency, fairness, recovery, deployment constraints and real path evidence.

24. Teach the Feedback Loop Before the RFC Vocabulary

Give learners a tiny network simulation with one bottleneck, one queue and a sender window. Ask them to predict what the sender sees one round trip after increasing the window. Only after they can reason about the feedback loop should terms such as fast recovery, ECN or cubic growth be layered on top.

This predict-run-investigate sequence aligns well with PRIMM, a programming pedagogy that deliberately asks learners to reason about code and state before constructing a full solution. See PRIMM.

25. Use Worked Traces, Then Remove the Numbers

Begin with a complete table containing round number, congestion window, packets sent, signal received and next window. Then hide the next-window column. Later give only the packet events and ask learners to reconstruct the controller state. Faded worked examples and Parsons-style code reconstruction reduce unproductive syntax load while the state-transition model is still forming.

Programming-education research increasingly treats scaffolding as something that should fade as competence grows rather than remain permanent. See the 2025 ACM literature review Teaching Algorithm Design: A Literature Review and recent work on faded Parsons problems.

26. Retrieval and Transfer Checks

• Immediate: update cwnd through a short ACK/loss trace.
• Counterexample: construct a case where high throughput coexists with terrible latency.
• Delayed: explain AIMD from memory without using the words “Reno” or “TCP.”
• Transfer: decide which measurements would distinguish loss-based and model-based behaviour.
• Coexistence: predict what must be tested when two different controller families share one bottleneck.
• Professional: design an experiment varying RTT, bandwidth, queue size, AQM, cross traffic, loss and flow duration.

The goal is not to recite RFC numbers. It is to reconstruct the control problem: what is observed, what is estimated, what action is taken, and how delayed feedback changes the next decision.

27. AI Assistance Boundary

AI can generate packet traces, explain RFC terminology, create simulator scaffolds and help compare public congestion-control descriptions. The learner should still be able to trace the feedback loop, distinguish signals from control actions, explain a controller’s state variables, identify coexistence risks and independently validate claims against standards and controlled experiments.

Professional Direction

Advanced study can branch into BBR variants, Copa, PCC, delay-based control, multipath congestion control, QUIC implementations, DCTCP, Prague-compatible scalable controllers, AQM algorithms such as CoDel and PIE, fair queueing, congestion-control verification, satellite and cellular paths, wireless loss, datacentre fabrics, real-time media and programmable transport stacks.

Algorithm-learning rule: never ask only “how fast does this controller send?” Ask what it believes about the path, which feedback changes that belief, how late the feedback arrives, what queues are doing, and whether the controller remains safe and fair when the rest of the network behaves differently.