Summary

  • RFC 5290 defended simple best effort as a common, low-overhead traffic class. Differentiated service can improve particular journeys, but it is an adjunct rather than a replacement for the baseline.
  • “Rough flow-rate fairness” is a goal assembled from choices about flow identity, time, RTT, packet size, protocol and enforcement. A fair-looking rate is not evidence that people, organizations or outcomes were treated fairly.

The service that asks the network for less

Simple best effort is easy to underestimate because much of its value is the absence of required machinery. In RFC 5290’s definition, the traffic does not rely on differential treatment in routers, policers, enforcers or other middleboxes, and it does not depend on admission control. That does not mean the surrounding Internet is socially or technically simple. Firewalls, bilateral ISP agreements, volume pricing and complex middleboxes can still exist. The claim is narrower: the packet’s basic chance to move does not require every path participant to recognize a premium contract or a special class.

That distinction is an architectural asset. The baseline does not require per-flow scheduling in every router. It does not require an inter-provider congestion ledger. It does not require an admission decision before an application can begin. An endpoint can use congestion-controlled transport while the intervening networks retain considerable autonomy. This is less precise than a system engineered for an explicit service guarantee, but it can cross administrative borders without first making those borders agree on the same economic and control model.

RFC 5290’s authors did not present the baseline as optimal. They presented it as useful. By 2008 it had carried file transfer, email, the web, media streaming and voice, imperfectly but broadly. It generally allowed competing users to obtain some share of available resources while avoiding the routine congestion collapse that had once threatened packet networks. Those are historical observations, not a measurement of any current network. Their continuing analytical value lies in the shape of the dependency: a widely usable service can be valuable precisely because it asks little of the shared core.

An adjunct has a boundary

The document is not an argument against quality of service. Some applications benefit from more bandwidth, less delay or jitter, fewer drops, faster startup, or a refusal to start when resources are inadequate. Simple best effort cannot promise all of those properties under congestion. Integrated services, differentiated services and other mechanisms were designed because those needs are real.

But an additional class and a replacement architecture are different decisions. A premium class can finance infrastructure or protect a latency-sensitive application. It can also, if the baseline has no protected share, let those able to pay starve those who cannot. The control question is therefore not merely whether priority exists. It is whether the ordinary class retains a usable denominator when congestion makes the classes contend.

This is the first evidence boundary. The presence of a differentiated-service marking proves that a packet was classified. It does not prove that every router on the path implemented the intended per-hop behavior, that capacity was reserved, that the baseline retained sufficient bandwidth, or that the application received its promised outcome. A commercial label, a scheduler configuration, a queue counter and an end-to-end result belong to different layers.

RFC 2475 describes differentiated per-hop behavior and traffic conditioning. RFC 2212 specifies a guaranteed-service model with explicit assumptions. RFC 3662 defines a lower-effort behavior that can sit below best effort. These are not interchangeable instruments. Each changes who must classify traffic, where state exists, what failure looks like and which evidence is needed. Their existence supports RFC 5290’s point that other classes can be useful; it does not dissolve the baseline they are arranged around.

A flow is not a person

The second boundary lies inside the word “fairness.” RFC 5290 describes rough flow-rate fairness as an acceptable goal for simple best effort, not an optimal allocation or a guaranteed right. In the Internet it observed, much of that approximation arose because most traffic used TCP and most TCP connections used broadly conformant congestion control. That is cooperation at scale. It is not ubiquitous enforcement.

Even a perfectly accurate flow-rate dashboard would leave the identity problem unresolved. Is one flow one TCP connection? All connections between two endpoints? All sessions from one subscriber? One application? One household? One company? If a client opens ten connections while another opens one, equal treatment of connections can produce unequal treatment of users. The rate can be calculated correctly while the unit of moral or commercial concern remains wrong.

The metric is no less political. Two flows with different round-trip times can receive different throughput under the same congestion response. A flow crossing two congested routers faces a different path from one crossing a single bottleneck. Packet fairness differs from byte fairness. Short bursts behave differently from smooth senders. Reliable unicast, unreliable unicast and multicast expose different cost structures. The time window matters too: equal rates during a connection do not imply equal daily consumption, equal expense or equal opportunity.

None of this makes measurement useless. It makes the measurement conditional. A defensible fairness record must name at least the grouping key, the interval, the unit, the bottleneck, the congestion signal, the transport response and the enforcement point. Without those fields, “fair” is an adjective attached to an invisible policy.

Cooperation is not enforcement

The baseline depends on endpoint congestion control to prevent senders from collectively exhausting the network. RFC 2914 explains the responsibility to respond to congestion; RFC 2309 discusses queue management and unresponsive flows; RFC 896 records why congestion collapse demanded defensive behavior. These sources make a subtler point than “the network has no control.” The shared class is minimal, but it is not lawless.

There are at least three different operating states. In the first, most endpoints voluntarily run similar congestion control and the network obtains a rough allocation with little router state. In the second, routers or middleboxes detect and restrain aggressive or unresponsive traffic. In the third, the infrastructure enforces a stronger fairness model through per-flow scheduling or another explicit mechanism. A result observed in the first state cannot be reported as if the third state produced it.

Traffic surges sharpen the distinction. A flash crowd or distributed attack can degrade every best-effort flow sharing a path. Aggregate rate limits or inspection may be necessary, but they add classification and authority: who defined the aggregate, which traffic was grouped, what threshold fired, how false positives were handled, and when the restriction ended. A protective action can be operationally justified while still requiring a receipt.

Deployment is part of the design

RFC 5290 treats incremental deployment as a first-order constraint. A scheme that needs ECN marking at routers, policing at both endpoints and new economic accounting between networks is not one feature. It is a chain of dependent commitments. Any missing link can convert an intended end-to-end property into a local configuration artifact.

The decentralized Internet described by RFC 1958 has no single owner able to impose that chain everywhere. Applications and endpoints can often change faster than shared infrastructure and inter-provider agreements. That asymmetry helps explain why a less exact common service can outlive more elegant proposals: it tolerates partial coordination.

The correct comparison is therefore not “plain service versus clever service” on a diagram. It is the full operating burden of each. Which routers must change? Which endpoints must cooperate? Which parties settle costs? Which class is available when a contract is absent, a marker is stripped, a domain is not upgraded, or a policy database disagrees? A design that performs beautifully only after universal coordination has an availability risk hidden inside its adoption plan.

What the RFC does not prove

RFC 5290 is Informational and not an Internet Standard. It records an argument and observations from 2008. It does not prove that present networks preserve a sufficient baseline, that current TCP traffic dominates in the same way, that a particular operator enforces rough fairness, that premium service harms ordinary users, or that one fairness definition should govern every context.

It also does not turn best effort into an outcome warranty. A packet admitted to the baseline may still be delayed, dropped or reordered. A congestion-controlled flow may still perform badly. A queue may be configured as intended while the application fails elsewhere. The baseline is an architectural permission to participate with minimal shared preconditions, not a receipt for successful delivery.

That limitation is the reason to preserve the distinction. If admission, treatment, enforcement and outcome are collapsed into one green status, the dashboard will claim more authority than any component actually holds.

Sources