Summary

  • RFC 3387 found a missing layer above QoS mechanisms: a packet could receive differentiated treatment before anyone had defined, authorized, verified or billed a coherent service.
  • Its durable contribution was a receipt map across edge, core and domain boundary—and a warning that premium capacity and centralized management could damage the best-effort system they were meant to improve.

Imagine the cleanest possible demonstration. A packet arrives with a class mark. A classifier recognizes it. A scheduler lets it leave before ordinary traffic. The router has done something real and observable.

Now ask what service was delivered.

Who was entitled to the treatment? Which quantitative promise applied? Had the path admitted enough resources? Did the same interpretation survive the next provider boundary? Who measured conformance, who could challenge that measurement, and what would be billed if the return path belonged to someone else? The queue has no answer. Its success is one receipt in a chain whose other links may not yet exist.

That gap was the subject of RFC 3387, published in September 2002 by members of the IRTF Service Management Research Group. The memo was Informational. It standardized no protocol and reported no completed deployment. Its value lay in noticing that work on differentiated forwarding was running ahead of the machinery required to turn forwarding behavior into an honest service.

Early IP management prized simplicity and avoided centralized control. Best effort fit that architecture: the network forwarded what it could, applications adapted, and management concentrated heavily on devices and statistics. QoS changed the object being managed. Once one flow could receive a different treatment from another, operators needed to say what that difference meant, who could request it and how it would be proved across a fragmented network.

RFC 3387 separated service definition from service embodiment. The definition had to describe the commodity unambiguously. The embodiment had to map that definition onto actual network capability. A policy object or service name could express intent, but intent was not resource admission. A configured mechanism could instantiate part of the design, but configuration was not measured delivery.

The memo distributed the missing work across three surfaces. At the access edge, a system needed admission control, authentication, authorization, billing support and verification that traffic remained within agreed parameters. It also needed interfaces for service verification, fault notification, re-instantiation and termination.

Inside the core, the work changed. Traffic engineering needed a view of available resources and congestion. Devices had to report capacity, receive forwarding instructions, detect faults and recover. RFC 3387 explored more centralized calculation because some decisions depended on network-wide information that no single forwarding hop possessed. But it also repeated the harder architectural question: did the benefits of putting a service function in the network outweigh its complexity and destabilization risk?

At administrative boundaries, the receipt chain became political as well as technical. Competing providers could need service signaling, accounting, verification, traffic measurement and billing exchange while refusing to disclose sensitive internal capacity. A bilateral SLA expressed one boundary agreement; a long path could require many. Concatenating those agreements did not automatically produce one quantitative end-to-end promise.

The memo considered bandwidth brokers and trusted third parties as possible components. It did not make them sovereign or mandatory. Their attraction was functional: somebody might coordinate admission, price, payment or verification without exposing every operator's internal network. Their danger was equally structural: a component introduced to simplify cooperation could become a centralized control point over peer domains.

Billing made the distinction impossible to ignore. RFC 3387 said billing had to be designed at service inception, alongside security. It was not practical to invent a bespoke billing and security system for every service, nor safe to assume that the provider carrying packets would also provide both functions.

RFC 2975 helps separate the records. Accounting collects information about resource consumption. Charging applies a tariff or price logic. Billing turns charges into a demand for payment. Payment settles that demand. These may use related data, but they are not one event. A counter can be accurate while the tariff is wrong; a bill can be correct while unpaid; payment can occur while the promised path still failed.

The same discipline applies to packet treatment. DiffServ defined per-hop behaviors and boundary conditioning. RFC 3387 said directly that a per-hop class guarantee was not an end-to-end guarantee. A customer paying a premium would care about bandwidth, delay and error bounds across the path. One domain's successful scheduling decision could not testify for every other domain.

The edge/core/boundary map therefore becomes a chain of limited receipts. A credential identifies a principal under stated rules. Authorization permits a request. Admission commits modeled resources. A classifier assigns packets. A meter observes selected traffic. A scheduler applies local treatment. Boundary records describe a handoff. Service verification compares observations with the contract. Accounting records eligible use. Billing makes a financial claim. The application observes whether the work actually succeeded.

None of those receipts should be promoted into the next one merely because the system lacks a better measurement.

The risk reached traffic that never bought a premium service. Reserved capacity can be idle yet unavailable to best effort. High-priority flows can consume resources that ordinary traffic would otherwise use. RFC 3387 warned that revenue-generating services could come at the expense of the less lucrative best-effort Internet. It did not present a measurement of that harm; it identified an incentive that any architecture would need to expose.

This is where Lu Heng's Running-Code Primacy sharpens the history. The common layer should specify only what interoperability and verifiable safety require. A provider needs enough shared semantics to recognize an authorized service at a boundary, measure the agreed parameters and settle responsibility. It does not follow that one central institution should control how every independent network provisions or prices the service.

Minimum Initial Specification gives the constructive rule. Define the boundary contract narrowly and deterministically. Keep internal capacity choices local. Let future mechanisms win by voluntary operational adoption. A common receipt format can support cooperation without turning the recorder, verifier or broker into the source of validity.

RFC 3387 did not finish this architecture. It left more questions than protocols. That incompleteness is the historical point. By 2002, it was possible to make a packet look privileged before the Internet could explain the full service surrounding that privilege.

The queue could distinguish packets. The operator still needed to define the service, admit it, prove it, account for it, settle it across boundaries and show that everyone else's best effort had not quietly paid the cost.

Sources