Mathematics matters in TCP congestion control because the internet is shared. A sender does not know the exact spare capacity of every link between two computers, yet it must decide how much data to place in flight. Send too cautiously and capacity sits idle. Send too aggressively and queues grow, packets are dropped, delays rise and everyone may receive less useful work.
TCP turns acknowledgements, loss signals and round-trip measurements into a feedback loop. It maintains a congestion window, increases that window while the path appears healthy and reduces it when evidence suggests overload. For students asking why mathematics is important in technology, this is a vivid example of rates, inequalities, exponential growth, additive change, multiplicative decrease and control stability shaping everyday web use.
Quick Reading Routes
- Students can begin with packets in flight, bandwidth-delay product and the slow-start table.
- Parents and teachers can use the shared-water-pipe and motorway analogies to connect rates with fairness.
- Computing learners can focus on cwnd, ssthresh, RTT, ACK clocking, AIMD and fast retransmit.
- Practitioners can review measurement ambiguity, bufferbloat, modern variants and experimental evidence.
Congestion Is a Shared-Capacity Problem
A network path crosses links and routers with finite transmission rates and finite queues. The bottleneck is the smallest effective capacity along the path at that moment.
If senders collectively offer traffic below available capacity, most packets pass promptly. Near capacity, short bursts wait in router queues. Above capacity for long enough, queues fill and packets are dropped or explicitly marked.
Delay before loss
Congestion does not begin only when a packet disappears. Queueing delay can rise substantially while every packet still arrives. A video call may feel poor because packets wait, even when throughput remains high.
Capacity changes
Wireless interference, competing traffic, route changes and server limits alter the effective path. The sender therefore cannot configure one permanent safe rate.
Distributed decision
Routers do not normally negotiate an exact rate with every TCP connection. Each sender infers conditions from end-to-end signals. Many independent feedback loops interact.
The Standard Foundation
The Internet Engineering Task Force’s congestion-control specification defines four intertwined algorithms: slow start, congestion avoidance, fast retransmit and fast recovery. The authoritative reference is RFC 5681: TCP Congestion Control.
The document specifies required and permitted behaviour, but real operating systems may implement newer congestion-control algorithms while remaining compatible with TCP’s reliability semantics. This article uses the RFC’s Reno-style ideas to teach the mathematics clearly.
Reliability and congestion are different
TCP sequence numbers, acknowledgements and retransmissions provide an ordered reliable byte stream. Congestion control decides how aggressively to use the path. A packet can be retransmitted because it was lost, but the loss also becomes evidence about offered load.
Flow control is different too
The receiver advertises how much buffer space it can accept. The sender is limited by both the receiver window and the congestion window. Roughly, usable flight is bounded by the smaller of the two.
The Congestion Window
The congestion window, usually written cwnd, limits data sent but not yet acknowledged. It is maintained by the sender and commonly measured in bytes, although examples often express it in segments.
If cwnd is 20 segments and 12 segments are currently unacknowledged, about eight more segments can be sent, subject to receiver and implementation rules.
Flight size
Flight size is the amount of data transmitted but not cumulatively acknowledged. It is an observed state; cwnd is a control limit. They are related but not identical.
Maximum segment size
The sender maximum segment size, SMSS, is the largest data segment used for calculations in the RFC. Counting segments without stating their byte size can hide important differences.
Effective sending rate
A rough upper bound is cwnd/RTT bytes per second. If cwnd is 1 megabyte and RTT is 100 ms, the rate implied by one window per round is about 10 megabytes per second. Protocol overhead and ACK behaviour change exact results.
Bandwidth-Delay Product
The bandwidth-delay product estimates how much data must be in flight to keep a path fully occupied.
BDP = bottleneck bandwidth × round-trip time.
Worked example
A path carries 100 megabits per second and has a 40 ms RTT. Convert 40 ms to 0.04 s. BDP is 100,000,000×0.04 = 4,000,000 bits, or 500,000 bytes.
About half a megabyte in flight can fill the pipe in this simplified case. A much smaller window leaves capacity idle. A much larger window may sit in queues rather than improve delivery rate.
Units matter
Bandwidth in bits per second multiplied by seconds gives bits. Divide by eight for bytes. Confusing megabits with megabytes creates an eightfold error.
BDP is not a guaranteed optimum
RTT includes propagation, processing and queueing. Capacity can vary. Multiple senders share the bottleneck. BDP is a useful reference, not a magic window.
Slow Start: Exponential Growth by Rounds
At the beginning, a sender has little evidence about path capacity. Slow start begins with a relatively small window and increases it quickly as acknowledgements arrive.
For each acknowledged segment, cwnd increases, so a full round can roughly double the window under simplified assumptions. The name “slow start” is historical; growth can be exponential.
A teaching table
Start with cwnd=1 segment.
- Round 0: 1 segment in flight.
- Round 1: acknowledgements permit about 2.
- Round 2: about 4.
- Round 3: about 8.
- Round 4: about 16.
- Round 5: about 32.
After r clean rounds, the simplified window is 2^r segments until a threshold or congestion signal changes the phase.
Why acknowledgements pace growth
The sender generally earns new sending opportunities as ACKs return. This ACK clock links transmission to evidence that earlier data left the network path.
Bursts and pacing
If a large window is released at once, packets can arrive at a bottleneck in a burst. Modern stacks may pace transmissions across time to reduce burstiness. The conceptual window remains important, but the schedule within the window also matters.
The Slow-Start Threshold
The slow-start threshold, ssthresh, separates rapid growth from congestion avoidance. When cwnd is below ssthresh, slow start applies; above or around it, growth becomes gentler.
After congestion, ssthresh is commonly set from the amount of data in flight according to the RFC’s rules, often approximately half with lower bounds.
Example transition
Suppose ssthresh is 16 segments and cwnd starts at 1. Simplified rounds reach 1,2,4,8,16. The algorithm then enters congestion avoidance instead of continuing to 32 in one round.
Threshold is memory
ssthresh records an estimate of where aggressive growth previously became unsafe. It is not direct measurement of link capacity.
Changing paths
A route change can make the old threshold too high or too low. Feedback eventually adapts, but transient behaviour matters.
Congestion Avoidance and Additive Increase
During congestion avoidance, a Reno-style sender increases cwnd by roughly one SMSS per RTT, rather than doubling it.
Per ACK, a common conceptual increment is SMSS²/cwnd. Across roughly cwnd/SMSS ACKs in one window, total increase is about one SMSS.
Worked arithmetic
Let cwnd=20×SMSS. Each ACK increases by about SMSS²/(20×SMSS)=SMSS/20. About 20 ACKs arrive for the window, so total growth is about one SMSS.
Linear sawtooth
Repeated additive increase raises the sending window linearly until a congestion event triggers a decrease. Plotting cwnd over time produces a sawtooth-like pattern.
Why not keep doubling?
Near capacity, doubling overshoots dramatically. Additive growth probes gently for newly available bandwidth.
Multiplicative Decrease
When congestion is inferred, classic AIMD reduces the window by a fraction, commonly about half for loss detected by duplicate acknowledgements.
If cwnd was 40 segments, a factor 0.5 reduction gives 20. If it was 21, implementation byte arithmetic and minimum rules determine the exact new value.
Why multiplicative?
A proportional cut reacts more strongly to a large sender than a small one. This helps competing flows converge toward a fair share under idealised assumptions.
AIMD
AIMD means additive increase, multiplicative decrease. Increase by a fixed amount per round; decrease by multiplying by a factor below one after congestion.
Not every modern algorithm is Reno AIMD
CUBIC, BBR and other algorithms use different models or window growth. The AIMD framework remains foundational, but avoid claiming every TCP connection follows the same curve.
A Two-Flow Fairness Picture
Imagine two long-lived flows share one bottleneck of capacity C. Let their rates be x and y. Efficient use lies near x+y=C. Equal sharing lies near x=y.
Additive increase moves the rate pair diagonally: both rise by similar amounts. When total rate exceeds capacity, multiplicative decrease scales both, moving toward the origin along a ray.
Geometric convergence
Repeated diagonal increases and proportional decreases can approach the intersection of efficiency and fairness lines. This phase-plane picture explains why AIMD is celebrated mathematically.
Assumptions
The neat convergence assumes flows observe comparable congestion, have similar RTTs and use compatible algorithms. Real flows differ in RTT, start time, packet size and bottleneck path.
RTT unfairness
A shorter-RTT flow receives feedback rounds more frequently and can increase its window faster per second. Equal additive growth per RTT is not necessarily equal growth per wall-clock time.
Round-Trip Time
RTT is the elapsed time from sending data to receiving an acknowledgement for it. It includes forward and return propagation, transmission, processing and queueing.
Minimum RTT and queueing
The smallest observed RTT approximates propagation plus unavoidable processing under a clear path. Current RTT minus minimum RTT gives a rough queueing component, although route changes and measurement noise complicate interpretation.
Worked queue estimate
Minimum RTT is 30 ms and current RTT is 80 ms. The extra 50 ms suggests queueing or transient delay. At a 20 megabit/s bottleneck, 0.05 s of queued transmission corresponds to about 1,000,000 bits, or 125,000 bytes.
Smoothed estimates
Retransmission timers should not follow every noisy sample. TCP maintains smoothed RTT and variation estimates. An exponentially weighted average balances responsiveness against noise.
Karn’s ambiguity
After retransmission, an ACK may correspond to the original segment or the retransmission. Using that sample can mismeasure RTT. Algorithms avoid ambiguous samples or use timestamps.
Packet Loss as a Signal
Classic TCP often treats loss as evidence of congestion, because full router queues drop packets. Loss can also come from corruption or link-layer events, so the inference is not perfect.
Retransmission timeout
If no useful acknowledgement arrives before the retransmission timer, the sender assumes serious trouble, retransmits and reduces its sending state strongly. RFC 5681 requires cwnd to restart conservatively after a timeout.
Duplicate acknowledgements
If later segments arrive while one is missing, the receiver repeats an acknowledgement for the last contiguous byte. Three duplicate ACKs can trigger fast retransmit before the timer expires.
Selective acknowledgements
SACK lets the receiver report non-contiguous blocks received. The sender can retransmit missing data more efficiently than relying only on cumulative ACKs.
Explicit Congestion Notification
ECN-capable routers can mark packets instead of dropping them, and endpoints echo that signal. Congestion control still reduces load, but useful data need not be discarded merely to communicate pressure.
Fast Retransmit and Fast Recovery
Three duplicate ACKs suggest one segment is missing while the path still delivers later segments. Fast retransmit resends the missing segment immediately.
Fast recovery avoids returning all the way to the smallest starting window. It reduces the threshold and adjusts cwnd while accounting for packets believed to have left the network.
Why duplicate ACKs carry information
Each duplicate ACK usually indicates another later segment reached the receiver. The path is not completely silent; some data is flowing.
Reordering
Packets can arrive out of order without loss. A low duplicate-ACK threshold can cause spurious retransmission. Modern mechanisms use additional evidence to distinguish reordering.
Recovery is stateful
The sender tracks which data is outstanding, acknowledged, retransmitted or suspected lost. A single counter cannot capture the full recovery process.
Queueing and Bufferbloat
Routers buffer packets to absorb bursts, but very large buffers can remain full. Throughput looks good while latency becomes terrible—a phenomenon called bufferbloat.
Simple queue delay
A queue of Q bytes drained at R bytes per second adds approximately Q/R seconds for a packet at the back, ignoring arrivals during the wait.
If Q=2 megabytes and R=10 megabytes/s, added delay is about 0.2 s.
Bigger is not always safer
More buffering reduces short-term drops but weakens the immediacy of congestion feedback and inflates RTT. Interactive traffic suffers behind bulk transfers.
Active queue management
Routers can mark or drop before the buffer is completely full, using queue delay or occupancy signals. The goal is to signal congestion while keeping queues controlled.
End-to-end interaction
Queue policy and sender algorithm form one control system. Evaluating either alone can be misleading.
Throughput, Goodput and Retransmission
Throughput counts bits transmitted across a link. Goodput counts useful application data delivered, excluding retransmissions and protocol overhead.
Example
A link transmits 100 MB in 10 seconds, but 12 MB are retransmissions and 3 MB are headers. Application goodput is 85 MB/10 s=8.5 MB/s, while raw throughput is 10 MB/s.
Congestion collapse
If senders respond to loss by injecting more duplicate traffic without reducing offered load, useful delivery can fall even while links stay busy. Congestion control protects goodput, not merely utilisation.
Completion time
For a short transfer, startup and RTT dominate. For a long transfer, steady-state rate matters more. One average throughput number does not describe both.
Modern Congestion-Control Families
Reno infers capacity through loss and AIMD. CUBIC grows its window as a cubic function of time since congestion, designed for high bandwidth-delay paths. BBR estimates bottleneck bandwidth and round-trip propagation time, aiming to operate near a modelled BDP.
Model versus signal
Loss-based schemes use loss or marking as primary congestion evidence. Delay-based schemes watch rising RTT. Model-based schemes estimate delivery rate and propagation. Hybrid designs combine signals.
Coexistence
Algorithms share real queues. A design that performs well alone may be unfair or unstable beside another. Testing needs mixed traffic.
Deployment claims
Do not say one algorithm is universally fastest. Results depend on path bandwidth, RTT, loss, buffering, wireless behaviour and competing flows.
A Worked Window Trace
Assume SMSS=1,500 bytes, initial cwnd=2 segments and ssthresh=16. Ignore delayed ACKs for clarity.
Clean slow-start rounds give cwnd 2,4,8,16 segments. Congestion avoidance then increases to about 17,18,19 and 20 over four RTTs.
At cwnd=20, three duplicate ACKs indicate loss. Set ssthresh near half the flight, roughly 10 segments, and after recovery continue around that scale according to the algorithm’s exact rules.
Byte values
At 20 segments, cwnd is 30,000 bytes. At 10 segments, 15,000 bytes. On a 50 ms path, the rough window-limited rates are 600,000 bytes/s and 300,000 bytes/s respectively.
Regrowth
Additive increase of one segment per RTT takes about ten clean RTTs to return from 10 to 20 segments. At 50 ms, that is about 0.5 seconds. At 200 ms, it is about 2 seconds.
RTT changes recovery speed
The same window algorithm evolves in feedback rounds, so long-distance paths adapt more slowly in wall-clock time.
Measurement and Experiment Design
To study congestion control, record sender algorithm, cwnd, flight size, delivered bytes, retransmissions, RTT samples, queue delay, ECN marks, receiver window and application completion time.
Controlled emulation
Emulate a bottleneck with fixed capacity, base RTT and queue limit. Repeat with one flow, then several, then mixed RTTs. Change one factor at a time.
Real-path caution
Internet routes and competing traffic change during a test. Use repeated trials, time stamps and confidence intervals. A single speed-test screenshot is weak evidence.
Percentiles
Report latency percentiles and transfer sizes, not only average throughput. Congestion often hurts tails first.
Ethical testing
Do not intentionally overload networks you do not control. Use local labs, authorised testbeds or carefully bounded traffic.
Misconceptions Worth Correcting
“Packet loss is always a broken cable”
Loss often comes from full queues, though corruption and wireless events also exist. Context determines the inference.
“A bigger window is always faster”
Beyond the useful in-flight amount, extra data queues, raises latency and can trigger loss.
“Slow start grows slowly”
Its simplified growth is exponential per RTT until a threshold or congestion event.
“TCP knows the link speed”
Classic TCP infers a safe operating point from end-to-end feedback. It usually does not receive an exact bottleneck-capacity announcement.
“Fairness means equal windows”
Different RTTs and segment sizes mean equal windows may not imply equal rates. Fairness needs a declared metric.
Which Mathematics Matters Most?
Rates and units connect windows to throughput. Exponential functions describe slow start. Linear increments and proportional cuts define AIMD. Geometry explains fairness convergence. Queueing connects buffers to delay. Probability and statistics support loss interpretation and experiments. Control theory explains stability, feedback delay and oscillation.
The existing article on DNS resolution, TTLs, caching and latency develops another source of network delay. Content delivery networks, cache-hit ratios, latency and invalidation shows how moving content closer changes RTT and traffic demand.
A Practical Learning Sequence
1. Convert bandwidth and RTT into a bandwidth-delay product with correct units. 2. Trace cwnd through five slow-start rounds. 3. Switch to additive increase at a chosen threshold. 4. Apply a multiplicative decrease and plot the sawtooth. 5. Compare two flows with different RTTs. 6. Add a finite queue and calculate queueing delay. 7. Measure goodput, retransmission rate and p95 latency in a safe emulator.
A spreadsheet activity
Create columns for time, cwnd, RTT, ACKed data and loss. Use formulas for doubling below ssthresh, +1 per clean round above it and ×0.5 on a congestion event. Plot cwnd and queue delay. Then vary RTT and compare wall-clock recovery.
A coding project
Simulate senders sharing a bottleneck. Each round, allocate delivered capacity, add excess to a finite queue and mark loss when full. Implement AIMD. Test equal and unequal RTTs, then report utilisation and Jain’s fairness index.
Guidance for Students
Keep bits, bytes, seconds and milliseconds explicit. Most wrong answers in network arithmetic are unit errors.
Separate specification from simplification. “cwnd doubles every RTT” is a useful slow-start model, not a word-for-word description of every ACK pattern or implementation.
Ask what signal an algorithm observes. Loss, delay, delivery rate and ECN marks carry different information. A graph is meaningful only when the axes and measurement process are known.
Guidance for Parents and Teachers
TCP congestion control makes algebra feel alive. Students can see exponential growth, proportional reduction and queueing delay in a familiar activity: loading a page or joining a video call.
Use the topic to reward careful explanation. A learner should be able to say why a bigger buffer can both prevent drops and worsen latency. Holding two effects at once is valuable systems thinking.
Encourage experiments on an authorised simulator rather than the public network. The goal is not to “break the internet” but to learn how cooperation keeps shared infrastructure useful.
Did You Know?
TCP’s window can be measured in bytes while people casually discuss it in packets. The byte view matters because packet sizes vary. Mathematics protects the explanation from a hidden unit change.
Another surprise is that congestion control is social as well as technical. Each sender pursues performance, but must react to shared signals so the network remains useful for others. Fairness emerges from feedback rules, not goodwill inside a packet.
Practice Problems With Solutions
Problem 1: BDP
A 50 Mb/s path has RTT 80 ms. BDP=50,000,000×0.08=4,000,000 bits=500,000 bytes.
Problem 2: Window-limited rate
cwnd is 240,000 bytes and RTT is 60 ms. Rough rate is 240,000/0.06=4,000,000 bytes/s, or 32 Mb/s before overhead.
Problem 3: Slow start
Starting at two segments, four clean doubling rounds give 2,4,8,16,32. If ssthresh is 16, the final jump to 32 should not occur under the simplified phase rule; switch to congestion avoidance at 16.
Problem 4: AIMD
A window of 30 segments experiences congestion and halves to 15. It then needs about 15 clean RTTs at +1 per RTT to return to 30.
Problem 5: Queue delay
750,000 bytes queued on a 15 MB/s link add roughly 0.05 s, or 50 ms, for data at the back.
Problem 6: Goodput
120 MB crosses a link in 12 seconds, including 15 MB retransmissions and 5 MB headers. Goodput=(120-20)/12≈8.33 MB/s.
FAQ
Is congestion control the same as rate limiting?
No. TCP adapts to network feedback. Application rate limiting enforces quotas or protects services. Read API rate limiting, token buckets, quotas and retry timing for that layer.
Why use a window instead of one fixed rate?
The window naturally links sending opportunities to acknowledgements and RTT. Modern implementations may also pace within the window.
Does every loss halve cwnd?
Exact response depends on algorithm and how loss is detected. Reno-style teaching uses multiplicative decrease, but modern stacks vary.
What is the most important graph?
Plot cwnd and RTT over time together. Window growth without latency context can hide a filling queue.
Can TCP eliminate congestion?
It manages and responds to congestion. Bursts, failures and competing algorithms still create queues and loss.
What should a student remember?
Estimate data in flight with BDP, grow quickly when capacity is unknown, probe gently near the limit, and reduce load when the path signals congestion.
Useful Next Reading
- Read observability sampling, histograms, percentiles and alert thresholds to measure latency distributions.
- Read load balancing, queue lengths, the power of two choices and tail latency for a service-side view of shared work.
- Consult RFC 5681 for exact normative requirements and definitions.
Final Perspective
One final discipline is to keep a measurement diary. Record when a sample was taken, which endpoint produced it, whether bytes or packets were counted, and whether retransmissions were included. Two dashboards can disagree while both are internally correct because they measure different boundaries. Before changing an algorithm, reconcile definitions. This small habit prevents a surprising amount of network confusion and gives students a practical model of quantitative honesty.
A Laboratory for Seeing Congestion Mathematics
Students can make this topic visible without building an internet-scale network. Use a simulator, a local test tool or simply a spreadsheet. Create columns for round number, congestion window, packets sent, packets acknowledged, estimated RTT, loss event and the next window. Begin at one segment. Double the window until a chosen threshold, then add one segment per round. At a predetermined loss round, cut the window in half. The resulting graph has a recognisable shape: steep early growth, a gentler ramp and a sudden drop.
Now change one assumption at a time. Raise the path capacity but keep RTT fixed. Increase RTT but keep bandwidth fixed. Add a second flow that begins later. Replace a sharp queue limit with an early warning mark. These are controlled experiments: one variable changes while others remain constant. The point is not to mimic every implementation detail. It is to connect an update rule with an observable consequence.
A useful extension compares equal additive increases with unequal RTTs. Suppose flow A completes ten feedback rounds while flow B completes five. Even if both add the same amount per round, A updates twice as often in wall-clock time. This helps students understand why a rule that looks symmetric on paper may not produce equal measured throughput. Fairness depends on the measurement clock as well as the formula.
For younger students, use tokens and cups. Each cup is one round. Tokens are packets. A returned token represents an acknowledgement and permits new work. A red card represents congestion. The sender may add tokens cautiously after success and remove a fraction after a red card. Physical modelling makes the control loop concrete before symbols are introduced.
Questions to ask after the experiment
- Did throughput increase every time cwnd increased?
- When did RTT begin to rise, and what might that say about a queue?
- Did a larger buffer improve useful delivery or mostly add delay?
- How long did recovery take after a loss?
- Were two flows equal by window, by rate, by delay or by completed bytes?
- Which conclusion depends on the simplified model and should not be generalised to every TCP implementation?
Design Trade-offs Hidden Inside a Simple Rule
AIMD is memorable, but engineering decisions surround it. A sender needs a starting point, a loss detector, a timer, a way to interpret duplicate acknowledgements and rules for resuming after idle periods. Measurements are noisy: acknowledgements may be delayed, reordered or compressed together. Wireless loss can resemble congestion loss even when the bottleneck is not full. A path can change during a connection. Encryption can hide some information from middleboxes while protecting users.
Each uncertainty invites mathematical discipline. State the measurement, its unit and its age. Distinguish a sample from an estimate. Avoid treating one packet loss as a complete diagnosis. Prefer multiple signals when available. A transport algorithm is therefore not only an equation; it is an inference process operating with partial evidence.
There is also a policy question. A more aggressive sender may win a larger share in the short term, but if every sender behaves that way, queues and losses rise for everyone. Congestion control illustrates a recurring idea in mathematics and society: individually tempting actions can degrade a shared resource. Stable protocols align local responses with collective usefulness.
A responsible interpretation of performance claims
When an article or benchmark says that one congestion controller is “faster,” ask: faster by which metric, on what path and at whose expense? A test should report bandwidth, base RTT, buffer size, loss process, competing traffic, duration and traffic direction. Median throughput alone may hide severe tail latency. A single laboratory path may not represent mobile networks or long-distance links.
Students should learn to read performance charts as conditional evidence. The experiment supports claims within its setup; it does not prove universal superiority. This habit transfers directly to statistics, science and responsible technology evaluation.
From Classroom Mathematics to Further Study
Primary learners can begin with sharing and repeated doubling. Lower-secondary students can work with ratios, rates, graphs and percentage reductions. Upper-secondary students can model piecewise sequences, compare gradients and calculate BDP. Students who know calculus can discuss rates of change and equilibrium ideas. Those learning probability can model random loss and estimate expected completion time.
Computer-science learners can implement a toy controller, run two simulated flows and test invariants. For example, assert that cwnd remains positive, that data in flight does not exceed the permitted window in the simplified model, and that a congestion event reduces the next target. Engineering learners can connect the control loop to feedback systems, stability and damping.
No single school subject owns the topic. Mathematics supplies the language; computing supplies executable models; physics helps with propagation; design asks what experience users feel; ethics asks whether shared capacity is treated fairly. That is precisely why the topic is valuable: it rewards transfer between domains.
A compact project brief
Build a spreadsheet model of two flows sharing a bottleneck. Give them different starting times and RTTs. Define a queue limit and record window, sending rate, queue size and loss each round. Produce two graphs, explain one surprising result and identify two limitations of the model. Finish by proposing one extra measurement that would make the conclusion more trustworthy.
TCP congestion control shows why mathematics matters every time many people share a network. Windows turn acknowledgements into a safe amount of work in flight. Exponential and linear growth explore capacity. Multiplicative decrease protects the common path. RTT reveals both distance and queues.
The deeper lesson is optimistic: no sender needs perfect global knowledge to cooperate usefully. Clear units, measured feedback and well-chosen update rules allow distributed participants to discover a workable operating point together.