Summary

  • RFC 3337 let one PPP session use separate AAL2 CPS Channel Identifiers for separate preemption classes. SSSAR's 64-byte fragments made it possible for a high-priority class to be scheduled between fragments of a large lower-priority packet.
  • The class identifier did not select the scheduler or provision the ATM virtual circuit. Classification, class-to-CID mapping, queue service, capacity, receiver reconstruction and application outcome therefore required separate receipts; the document's 100 ms and fair-scheduler examples were conditional, not universal guarantees.

A label could describe intent without exercising authority

Quality-of-service systems often begin by naming traffic. A classifier decides that one packet belongs to voice and another to ordinary data. The name feels consequential because it is expressed in protocol state. Yet a label has no physical authority over a transmitter. Something else must read it, choose among queues and place bytes on the wire.

RFC 3337 made this distinction unusually visible. It extended PPP over AAL2 so a single PPP session could span multiple AAL2 Common Part Sublayer Channel Identifiers. Each preemption class used a different CID. That separation gave the CPS scheduler something concrete to choose between.

But the AAL2 CPS specification did not prescribe how that choice had to be made. RFC 3337 named priority, fair and weighted-fair scheduling as different possibilities. The method depended on the real-time requirements of the application. A correct class-to-CID mapping was therefore an input to a scheduling decision, not the decision itself.

One large packet could occupy a slow circuit for about 100 milliseconds

The document's motivating arithmetic was blunt. A 1,500-byte packet on a 128 kbit/s ATM virtual circuit occupies the link for roughly 100 milliseconds. If the transmitter must finish that packet before sending a newly arrived voice packet, the serialization delay alone can make an interactive exchange unacceptable.

Increasing priority after the large packet has begun transmission does not recover those milliseconds. The system needs a smaller preemption unit. RFC 3337 reused the Service Specific Segmentation and Reassembly function already required by PPP over AAL2. SSSAR divided PPP packets into 64-byte fragments. A high-priority fragment could then be placed between fragments of lower-priority traffic.

The 100 ms number was an example derived from one packet size and one circuit rate. Faster circuits reduce it; different framing and scheduling change the boundary. Its historical value is not a benchmark. It exposes serialization as a control surface that a class label cannot alter unless the transmitter may interrupt at fragment boundaries.

A class needed its own CID before a scheduler could see it

RFC 3337 required fragments from different preemption classes to use different CIDs. Each PPP session needed at least as many CIDs as it had preemptible classes. The classifier acted as packets entered fragmentation; its output selected the SSSAR instance and CID for the resulting fragments.

The standard did not impose one classifier. It referred to possible methods in the low-bitrate services architecture. Its voice example used packet size: small packets were treated as real-time and large ones as data. Even there, the threshold varied with the application and the transmission rate.

Size is an expedient signal, not semantic proof. A small control packet may be non-real-time; a large media repair object may be urgent. A stale rule can classify perfectly according to its syntax while violating the current service intent. Evidence therefore begins with classifier version, input fields, rule match, output class and the policy authority that approved them.

The scheduler was the missing verb

Once fragments occupied separate CID queues, the scheduler decided what the label meant in time. Strict priority could minimize one class's waiting while starving another. Fair scheduling could ensure alternation without honoring the tightest latency target. Weighted fair scheduling could allocate a proportion, yet still permit a burst to create an unwanted queue.

RFC 3337's example assumed two classes and a fair scheduler. Under those conditions, a real-time fragment would wait for at most one non-real-time fragment before transmission. That is a useful bound, but it is not zero delay and not an end-to-end voice guarantee. It rests on the 64-byte fragment size, the existence of two distinct CIDs and the chosen fair scheduling behavior.

Change any element and the conclusion changes. Add more queues, use a different quantum, map both classes to one CID, or implement fairness at a larger batch boundary, and the wait bound must be derived again. The scheduler algorithm and its active parameters belong beside the class in any latency claim.

Capacity was a separate gate

The voice example added a condition sometimes omitted from summaries: to guarantee low latency and loss, the ATM virtual circuit had to be provisioned with an appropriate real-time traffic class, such as VBRnrt or VBRrt. The class extension could order fragments; it could not manufacture service capacity.

A scheduler facing an overloaded circuit can only choose which promises to break. Admission control, traffic contract, shaping, policing and downstream contention determine whether the preferred class has enough resources. A packet may leave the local CID queue promptly and encounter a larger queue at the next boundary.

This separates three different meanings of “priority.” Classification says how a packet should be treated. Scheduling says which eligible fragment is served next. Provisioning says whether enough service exists for the treatment to produce the intended result. Conflating them makes configuration look like performance evidence.

Receiver success remained another chain

SSSAR fragmentation used the base PPP/AAL2 rules. UUI state marked intermediate and final fragments, and the receiver reconstructed the PPP packet. A scheduler receipt proves only that a fragment won a transmission opportunity. It does not prove every fragment arrived, the CRC passed, PPP accepted the packet or the application used it before its deadline.

The useful receipt chain preserves classifier input and output, class-to-CID mapping, fragment and UUI sequence, per-CID queue arrival and departure, scheduler choice, ATM traffic contract, cell transport, SSSAR result, CRC, LCP state and application outcome. Each transition has a different owner and clock.

Voice quality adds jitter buffers, codecs, playout deadlines and loss concealment. A bounded local serialization wait may be necessary while remaining insufficient. The endpoint, not the class label, supplies the final evidence.

Neighboring RFCs define the comparison without proving adoption

RFC 3336 supplied the base PPP over AAL2 mapping. RFC 2689 described the wider architecture for integrated services over low-bitrate links. RFC 2686 defined the Multi-Class Extension to Multi-Link PPP, while RFC 1990 supplied the multilink base. RFC 2508 addressed IP/UDP/RTP header compression, another part of reducing real-time overhead.

RFC 2474 and RFC 3246 provide differentiated-services context: a field or per-hop behavior can express or implement treatment elsewhere in a network. They do not prove an RFC 3337 class-to-CID mapping, and an EF marking cannot serve as a receipt for an AAL2 scheduler. RFC 2119 explains the requirement words used by the standards, not deployment.

None of the documents proves that a carrier enabled the extension, chose a compliant classifier, configured a particular scheduler, provisioned sufficient capacity or delivered a measured latency. Standards show available mechanisms and obligations. Operational history needs configuration and measurement.

The durable lesson is to locate the executor

RFC 3337 did something valuable by separating traffic into CIDs. It created an addressable scheduling surface where high-priority fragments could pass between pieces of a large packet. The mistake would be to stop the explanation at the label.

Every service promise contains nouns and verbs. “Voice class” is a noun. Classifying, mapping, fragmenting, scheduling, admitting, transmitting, reconstructing and playing are verbs performed by different components. A latency guarantee exists only when the verbs are specified, resourced and observed.

The historical question is therefore not whether the packet carried a class. It is which mechanism read that class, what authority it exercised at that moment, and what evidence survived at the receiver. RFC 3337 made differentiated treatment possible. It also left enough discretion to show why possibility is not proof.

Sources