Summary

  • RFC 9743 says a general-use congestion-control proposal without empirical Internet-scale deployment evidence must seek Experimental status; Experimental specifications should not be defaults and should run only where they are actively measured and can be deactivated if pathology appears.
  • Standards status and runtime control are separate receipts. Publication does not choose a product default, define a rollout population, prove that monitoring covers harmed traffic or exercise the path that returns a fleet to a known fallback.
  • Evaluation must follow the algorithm across competing traffic, queues, path types, transient events and deployment boundaries. A favourable average or a standards label cannot replace a versioned evidence packet and a tested stop decision.

The release manifest said Experimental. The rollout controller said enabled for 20 percent. The dashboard was green. Nobody in the change record was named as the person who could turn the algorithm off.

That missing name is not a clerical defect. It is the boundary between a reversible experiment and an unmanaged production policy.

RFC 9743, published as Best Current Practice 133 in March 2025, is about how the IETF should evaluate specifications for new congestion-control algorithms. It does not define an algorithm and it does not control a product release. Yet one of its most operationally important sentences crosses directly into release governance: Experimental specifications should not be deployed as a default, and should be used only where they are actively measured and can be deactivated if signs of pathological behaviour appear.

Three verbs do the work: default, measure, deactivate. Each belongs to a different record. A standards document can recommend. A product team chooses the default. A telemetry system measures some population. An operator or automated controller executes a stop. Treating the word Experimental as if it performed the other three jobs is how a careful standards category becomes a decorative badge.

Publication is not the deployment gate

RFC 9743 begins by dismantling a comforting fiction. New congestion control is not necessarily waiting for an RFC. It recounts how CUBIC was widely used before it reached Standards Track and how BBR developed and deployed outside a completed IETF standardization path. Publication still matters: it gives implementers a shared account of the algorithm, exposes ambiguity, enables independent implementations and makes proposed changes discussable. But the RFC is not a switch between laboratory and Internet.

That distinction cuts in both directions. Lack of Standards Track publication does not prove absence from production. Standards Track publication does not prove that a particular binary, configuration or network is safe. The document describes a proposal and the community's review; the running system still has a version, implementation history, target population and local operating authority.

RFC 9743 therefore links status to evidence maturity rather than to a metaphysical judgment about goodness. Experimental and Standards Track proposals face the same broad questions, but the expected answers and certainty differ. A general-use proposal without empirical Internet-scale deployment evidence must seek Experimental status. A proposal with measured Internet-scale deployment may seek Standards Track directly if solid data reflects safety and design stability. Even then, the data does not waive the rest of the evaluation.

The word may matters. Scale is evidence, not absolution. A billion successful connections can say much about common paths and still say little about the rare queue, the synchronized failover or the competing real-time flow that the measurement did not isolate.

An experiment needs a population, not only a label

“Actively measured” sounds precise until someone asks what is being counted. An experiment needs an algorithm version, implementation build, configuration, enabled cohort, baseline cohort, traffic class, observation interval and competing algorithms. It needs denominators for loss, latency, throughput, starvation and fallback. It needs to say whether the observer can see only the new algorithm's own flows or also the flows it may displace.

A dashboard can be entirely accurate and still answer the wrong question. If it reports throughput only for participating connections, it may miss harm to Reno, QUIC or CUBIC traffic sharing the bottleneck. If it reports completion only for long flows, it may miss short flows that never leave slow start. If it averages across the fleet, it may hide a small path class with changing minimum delay. If it samples after the sender, it may never see application abandonment.

RFC 9743 is unusually clear that harm is not limited to unequal bandwidth shares. Mixed-algorithm evaluation must consider latency, packet loss and starvation, including backoff when all feedback disappears. A new algorithm need not be strictly Reno- or CUBIC-friendly in every environment, but coexistence with major deployed algorithms must be considered. Real-time traffic adds another geometry: it may seek finite throughput and tighter latency rather than every available byte.

The evidence packet must therefore retain the traffic that lost, not only the algorithm that won.

The same question has several evidence surfaces

RFC 9743 does not prescribe one universal test method. Simulation can explore wide parameter ranges and overload. Emulation and laboratory experiments can make mechanisms repeatable. Independent implementations can expose assumptions hidden in a reference codebase. Controlled deployments can show behaviour under a bounded operating authority. Internet-scale measurement can reveal common interactions that a lab could not reproduce.

These surfaces are complementary, not a maturity ladder in which the last erases the earlier ones. Internet scale can supply strong ecological evidence while making rare conditions difficult to identify. A deterministic lab can expose one failure mode while saying nothing about prevalence. Two implementations can agree because the specification is clear, or because both copied the same unstated assumption. A positive benchmark can establish performance under its declared topology without certifying the rest of the Internet.

RFC 9743 says implementation experience should normally precede Experimental or Standards Track publication, and that independent teams help test ambiguity. It also allows a narrower case: a single implementation may still support publication, particularly Experimental, if it is widely used, open source and shown to have positive Internet impact. The rule is not “two codebases equal truth.” It is an evidence argument whose exceptions must remain visible.

Status is a statement about certainty, not a runtime guard

For general Internet use, a proposal without empirical Internet-scale evidence must seek Experimental status. The Experimental specification ought to say why and what evidence would be needed for progression. That creates a useful missing-evidence ledger. It tells readers not merely that uncertainty exists, but which uncertainty remains material.

RFC 9743 also requires an algorithm specification's abstract to state whether IETF consensus considers it safe for Internet use and to identify environments where deployment is not recommended. Safety and recommendation are separate. An algorithm can be considered safe in an environment yet perform poorly enough that use is not recommended. Conversely, calling something Experimental is not a finding that it is unsafe.

None of these sentences reaches into a binary and changes a default. None creates a cohort. None defines an alert. None grants an incident commander authority. A status label can constrain the decision-maker's burden of proof; it cannot execute the decision.

The release record should therefore contain its own claims: why the chosen default is appropriate, how the target population differs from the evaluated population, which uncertainties remain, which metrics would reveal harm, and which actor can reverse the choice. The RFC reference is one input to that record, not the record itself.

Evaluation is a matrix, not a pass mark

RFC 9743 refuses to reduce congestion control to one score. It asks whether an algorithm protects against congestion collapse, excessive queues and high packet loss. It asks how its own flows share capacity, how short and long flows affect one another, and how it competes with standard and widely deployed controls. It asks about incremental deployment and departures from established congestion-control principles.

General-use evaluation must include tail-drop queues. Algorithms relying on explicit path signals must consider tunnels that hide flows or alter signals. Wired paths provide a useful baseline, while wireless paths add radio loss, changing capacity, media-access delay and retransmission jitter.

Special cases widen the matrix: active queue management, circuit breakers, changing minimum delay, constrained nodes, high-delay paths, malicious participants, extreme reordering, routing and mobility transients, abrupt path changes, multipath and data centers. RFC 9743 explicitly notes that Internet-scale deployment may not expose non-ubiquitous cases. The largest sample is not necessarily the most discriminating sample.

The document generally avoids universal numeric thresholds. The community must consider the criteria; when a recommended criterion is not met, it must document why that gap is acceptable. This is judgment under evidence, not checkbox compliance. A release team that imports the headings but drops the arguments has copied the form and discarded the control.

Controlled environments need an enforceable edge

An algorithm designed for a controlled environment can use evidence from that environment instead of proving general Internet behaviour. That is not a loophole. RFC 9743 asks how use is scoped, whether the flows share resources with Internet traffic and what happens if the protocol is bridged onto an Internet path. It asks whether a written restriction is enough or whether protocol mechanisms must enforce the boundary.

“Data center only” is therefore a claim about topology and control, not a marketing category. A tunnel, shared edge, hybrid workload or fallback route can move traffic outside the assumed envelope. The evidence packet needs the enforcement mechanism and the bridge failure mode. A private address, deployment tag or internal documentation page does not by itself keep an algorithm confined.

The same discipline applies to defaults. A non-default experiment can become effectively default when enrollment expands, when the old path disappears, when an opt-out is inaccessible or when new installations inherit the flag. The meaningful measure is exposure, not the boolean's name.

An off switch is a chain of effects

“Can be deactivated” is stronger than “has a configuration option.” A real stop path has an authorized caller, authenticated control, target resolution, propagation bound, behaviour for existing connections, fallback algorithm, state-reset rules and readback. It has been exercised against the same release machinery used for enablement.

Stopping new enrollment may leave existing connections on the algorithm. Changing a default may not change pinned policy. Rolling back a binary can preserve cached state. A fallback algorithm can inherit a congestion window that means something different. A controller can accept the command while part of the fleet is partitioned. The experiment is not safely reversible until those transitions have been tested and the post-change traffic has been measured.

RFC 8084's network circuit-breaker concept supplies a neighbouring protection layer: a network can monitor excessive resource use and terminate or sharply reduce traffic. RFC 9743 expects a well-designed algorithm to act before that envelope is reached. A circuit breaker is not a substitute for the algorithm's own safe behaviour, just as the product off switch is not a substitute for standards evaluation. Each control has a scope and an owner.

Promotion is a new decision

Moving an algorithm from Experimental toward Standards Track changes a publication claim. Moving it from opt-in to default changes exposure. The two changes can occur together, but one does not authorize the other.

A credible promotion packet should reproduce the evaluated algorithm and connect it to the shipped build. It should preserve unfavourable results, missing scenarios and measurement limits. It should show which environments were excluded and whether those exclusions remain enforceable. It should identify what changed since the Experimental statement and what evidence closes each declared gap.

A default-on decision needs additional local evidence: fleet mix, queue and path distribution, competing algorithms, user workloads, rollback capacity and support consequences. Standards consensus can inform that decision. It cannot assume its liability.

RFC 9743's deepest lesson is not that experiments are dangerous. It is that uncertainty must be operationally owned. A responsible experiment names the population, observes both beneficiaries and neighbours, retains the evidence needed to reproduce the judgment and can stop without inventing the control path during the incident.

The label belongs on the document. The off switch belongs in the running system. Safety depends on keeping both honest about what they can prove.

Sources