Summary

  • IntServ offered per-flow precision and an admission answer, while DiffServ offered aggregate scale and could leave an unhonoured request silent.
  • RFC 2990 identified two absent signals: resource availability from the core to the boundary, and success or failure from the boundary to the application.
  • A premium class became accountable only when discovery, admission, delivered-service measurement and usage accounting formed one closed loop.

The request travelled farther than the answer

Quality of service is often pictured as a packet entering a faster lane. RFC 2990 began one layer earlier. A different response from a finite network required both a behaviour and a rule that controlled how much load entered that behaviour. Priority without admission could merely move congestion. A promise without capacity could become a label applied to scarcity.

The two leading architectures placed that control in different locations.

Integrated Services let an application describe a flow and ask for resources along its path. Honoured requests created remembered reservation state. Routers needed classifiers, meters and scheduling state associated with those flows. This architecture could give an application a meaningful refusal: a node could reject the request rather than silently pretend that the resources existed.

Differentiated Services moved toward aggregation. A packet carried a code that selected a per-hop behaviour, while boundary functions classified and conditioned traffic entering a domain. Interior routers did not need to remember every application reservation. That was the source of its scaling power.

It was also the source of a different uncertainty. A request could be marked, admitted at one edge and carried into an aggregate even when the service could not be sustained along the interior path. RFC 2990 stated the consequence plainly: in the stateless model, the network was not required to tell the application that its request could not be honoured. The application was left to infer the failure from the service it observed.

The request had a forward path. The refusal did not yet have a defined route home.

Precision had a state cost

RFC 2990 did not describe IntServ as simply correct and DiffServ as simply weak. It made the trade-off structural.

An IntServ reservation joined several facts: the application's traffic profile, a path, resources reserved on that path, classification rules and conformance meters. Each active element had to retain enough state to recognize and service the flow. The computational and memory burden grew with the number of reservations. Fine-grained scheduling could also touch the forwarding path of the busiest routers.

That precision was expensive precisely where a carrier core needed to handle the most traffic and the greatest number of flows.

DiffServ compressed many flows into a small set of aggregate behaviours. The core could act on a codepoint instead of recreating an application's entire negotiation. Router state no longer had to increase in direct proportion to the number of clients. The result was scalable because the interior knew less.

The architectural question was therefore not whether state was good. It was where precision was worth its cost, where aggregation was safe, and how the less-informed part of the network would report back to the part making promises.

The missing middle was a signaling problem

RFC 2990 called DiffServ boundary-centric. That phrase named both its operational strength and its incomplete control loop.

At the boundary, an operator could classify, police and admit traffic into behaviour aggregates. In the interior, routers could deliver aggregate treatment efficiently. But the architecture did not define how changing resource availability inside the domain reached the boundary traffic conditioners. A boundary could be applying yesterday's assumption to today's congestion.

Nor did the model define how the boundary told an application that the desired response was unavailable. The application might continue sending a profile that only made sense under the requested service. It might pay for a premium class, adapt too late, or misdiagnose the resulting delay as an endpoint problem.

RFC 2990 therefore asked for two distinct signals:

  1. a core-to-boundary account of available resources; and
  2. a boundary-to-application account of admission or failure.

Collapsing them would obscure authority. Interior measurements could inform a boundary without granting an application resources. A boundary decision could refuse a flow without proving what the application later experienced. Each transition needed its own evidence.

Discovery preceded admission

The RFC found another missing step before the request even reached a boundary. Both IntServ and DiffServ generally assumed the best-effort routing path. That path might be the lowest routing metric and still lack the service capability the application needed.

In a piecemeal deployment, a service-capable path might coexist with ordinary paths. Yet neither architecture supplied a robust way for an application to ask which candidate path could support a particular profile. Marking a packet did not discover another route. Reserving on the already selected route did not prove that it was the best service path.

RFC 2990 linked this problem to QoS routing. A useful path metric would not merely count idle bandwidth. It would estimate the path's potential to carry additional traffic at a chosen quality, including whether lower-priority traffic could be displaced elsewhere. That was a policy-laden measure of optionality, not a neutral inventory of unused capacity.

Discovery, selection and admission were three decisions. A codepoint could not make them synonymous.

TCP exposed the reverse path

The document's TCP discussion supplied a practical warning against one-way models. A TCP sender used returning acknowledgements to time subsequent transmissions. If forward data received one service profile while reverse acknowledgements received another, the delivered application performance was a result of both paths.

Jitter could compress acknowledgements into a burst. The sender could answer with a burst of data that stressed the very service capacity intended to protect it. A symmetric profile might help, but then the architecture had to say how both directions were requested and how their resource use was counted without charging twice.

This was more than a TCP detail. A service could not be evaluated only at the location where the packet carried its class. The feedback that controlled the traffic might travel in the other direction and under another policy.

Measurement turned treatment into a claim

RFC 2990 separated resource measurement from delivered-service measurement.

The first fed admission: what could the network safely accept along a path? The second tested performance after admission: did the service delivered to the client conform to the specification?

Both parties needed that second record for different reasons. An operator needed objective evidence to substantiate a service claim. A client needed evidence that an extra expense bought superior application performance. Queue configuration, a packet mark or a successful reservation exchange could not substitute for observed delivery.

This distinction matters because service classes create a temptation to bill the request rather than prove the result. RFC 2990 anticipated premium tariffs and the use of price to moderate demand for scarce resources. It then noted that no accounting model or data-collection method had yet been defined to connect premium use to a particular client.

A complete commercial loop required at least: identity, entitlement, request, admission, resource allocation, observed delivery, attributed use, tariff rule and invoice. The RFC did not claim to have built that chain. It identified the links that were missing.

The hybrid architecture was an interface contract

RFC 2998, published the same month, described how an IntServ request could traverse a DiffServ region. RFC 2990 used that work to show a possible division of labour: per-flow interaction at the edge, aggregate behaviour in the core.

An application could use RSVP to request service. Boundary systems could map the flow to a compatible DiffServ aggregate. The core could avoid per-flow state while the wider path retained an application-facing reservation conversation.

But aggregation did not erase failure. For a high-precision end-to-end service, an admission failure inside the DiffServ region had to be communicated back to the application. If available aggregate capacity was static, boundaries could be configured with that limit. If availability changed dynamically, the core needed a live signal into the RSVP environment.

The hybrid was therefore not magic compatibility between two labels. It was an interface contract between two different truth models. One side knew individual requests. The other knew aggregate capacity. The architecture succeeded only if the boundary reconciled them and returned failure before the application treated silence as success.

No universal architecture, no universal receipt

RFC 2990 expected heterogeneous deployment. Some networks would differentiate service; others would not. Some mechanisms would interoperate cleanly; others would need bridges. The number of possible paths would acquire another dimension because their service capabilities could differ.

That diversity made discovery, invocation and measurement equally necessary. It also weakened the case for one universal QoS architecture. The conclusion instead favoured tailored combinations: aggregate mechanisms where core scalability dominated, per-flow mechanisms where edge precision was affordable.

Lu Heng's minimum-initial-specification lens clarifies the institutional virtue of that conclusion. A common architecture could define the smallest interfaces needed to exchange a request, capacity fact, decision and result. It did not need to centralize every operator's resource policy. Local decision remained legitimate only if its boundary was observable.

The reality-layer lens supplies the evidence discipline. A codepoint was not an admission. Admission was not capacity. Capacity was not treatment. Treatment was not measured application performance. Measurement was not attributed usage. Usage was not an invoice.

Running code had to close the loop. Otherwise the network could decline without saying no.

Sources