RFC 3133: When a Good Delivery Ratio Hid Bad Performance

Summary

RFC 3133 defined payload- and frame-delivery ratios for one direction of one Frame Relay virtual connection, with committed and excess traffic kept separately visible.
It also warned that a small lost acknowledgement could provoke many data retransmissions: the ratio could remain good while the application and its user experienced poor performance.

The numerator won; the user lost

Imagine a transfer crossing a Frame Relay virtual connection. Hundreds of large data frames pass. One small frame returns in the other direction to acknowledge progress, and that frame is discarded. The delivered-octet total barely moves. The delivered-frame percentage still rounds into reassuring territory. Yet the sender, deprived of the control evidence it needed, transmits many data frames again.

That was not a later criticism imposed on an old metric. RFC 3133 used essentially this example in its own discussions of Data Delivery Ratio and Frame Delivery Ratio. The memo did not say the ratios were useless. It said something more exacting: they might not represent delivery effectiveness for a given application.

The distinction mattered because the ratio was doing its assigned job. It counted declared things crossing a declared boundary. The application depended on causal structure that the count did not preserve. One acknowledgement could be small in bytes and singular in frames while carrying authority over a much larger volume of subsequent work.

The historical lesson is not that percentages lie. It is that a percentage inherits the evidence limits of its numerator, denominator and observation point. RFC 3133 made those limits unusually visible.

A physical rate was not a service promise

Frame Relay exposed several rates that could easily collapse into the word bandwidth. RFC 3133 refused the collapse.

The access channel was the user-facing physical channel—perhaps an unchannelized or fractional T1 or E1 arrangement. Its Access Rate described how quickly the user could inject data into the network. But the memo warned that this physical speed need not equal the service available under the agreement.

Committed Information Rate, or CIR, was the transport rate the network would maintain between service locations when data was presented. Committed Burst Size, Bc, named the number of bits the network agreed to transfer under normal conditions during a measurement interval, Tc. Burst Excess, Be, named uncommitted traffic above Bc that the network might attempt to deliver with lower probability.

Tc itself was not a periodically opening clock bucket. RFC 3133 described it as a sliding measurement interval triggered by incoming data and derived from Bc divided by CIR. That detail matters. Classifying traffic as committed or excess required the service contract and the traffic's timing, not merely a port-speed label.

Above CIR and below the excess allowance, traffic could be marked Discard Eligible. The DE bit was a preference under congestion, not a receipt proving that a frame had vanished. The document separated a discardable frame from a discarded one. A marked frame might survive because congestion cleared. An unmarked frame might still be selected through per-PVC or upper-layer policy. A malformed frame could be thrown away for an error rather than congestion.

This was a vocabulary for reconstructing decisions. Access rate, contracted rate, offered load, eligibility and actual discard were different facts owned by different mechanisms.

The metric lived in one direction of one circuit

RFC 3133 inherited the definition discipline of RFC 1242 and the BMWG tradition. It divided background terms from performance metrics and distinguished terminology documents from methodology documents. A metric name did not by itself specify a full test procedure.

Data Delivery Ratio, DDR, measured successfully delivered payload octets against attempted payload octets. It excluded the address field and frame check sequence. Frame Delivery Ratio counted successfully received frames against attempted transmissions. Both were scoped to one direction of a single virtual connection.

That last sentence prevents several common promotions of the evidence. A full-duplex connection had a separate ratio in each direction. One virtual connection's result did not describe every circuit on a port. A network-side ratio did not automatically include what happened before the ingress observation or after the egress observation. And payload-octet delivery was not the same observable as frame delivery.

The memo also allowed the total ratio to be decomposed. DDR_c and the corresponding frame ratio described load within the committed rate. DDR_e and its frame counterpart described excess load. A combined number could be arithmetically correct while hiding a severe difference between contracted and opportunistic traffic.

This was measurement as jurisdiction. The ratio had authority over a population only after the population had been named: which circuit, which direction, which interval, which load class, which payload definition and which observation edges.

One control frame could outweigh its size

The acknowledgement example reveals why even careful scope is not sufficient for an application conclusion.

An octet ratio weights a large data frame more heavily than a small acknowledgement because it counts bytes. A frame ratio gives them equal weight as two frames. Neither method records that the acknowledgement may release sender state, advance a window, prevent a timeout or avoid retransmission of many preceding frames. The control value of the frame is not a function of its length.

Suppose 999 data frames and one acknowledgement were offered, and only the acknowledgement disappeared. The exact arithmetic would depend on sizes and on what the test declared, so RFC 3133 did not supply this invented run. But its mechanism is clear: the frame ratio would be 99.9 percent and the octet ratio could be even closer to 100 percent. The sender's later retransmission volume and completion delay are outside those two original fractions.

It would be equally wrong to reverse the claim. One lost acknowledgement does not always produce a large penalty. A later cumulative acknowledgement might arrive. A timer, window, application pattern or transport implementation could change the result. RFC 3133 offered a counterexample to equivalence, not a universal law of harm.

The proper conclusion is conditional: good delivery statistics do not prove good application performance. To make the application claim, an observer needs another evidence chain—control-frame receipt, transport state, retransmission behavior, completion time and user-visible outcome.

Delay averages had a missing population too

The same discipline appears in Frame Transfer Delay. RFC 3133 defined a frame exit event at one boundary and a frame entry event at another. Delay was computed for received frames between those measurement points. Frames transmitted during the interval but never received did not enter the average.

That is mathematically coherent. It is also a reason to read the loss and delay statistics together. A low average delay can coexist with a missing tail if the frames that would have been slowest or never arrived are absent from the calculation. The average describes survivors.

Frame Transfer Delay Variation used the difference between the maximum and minimum observed delays. The memo connected large variation to TCP round-trip-time calculation and throughput, and excessive delay to applications such as voice over IP. It did not report a deployment or promise an application result. Again, the statistic located a symptom; it did not inherit authority over the whole service.

A dropped frame could be the correct outcome

RFC 3133 also resisted treating every discard as equivalent damage. It listed structural and integrity reasons for discarding frames: invalid lengths, bit alignment, unrecognized DLCI, abort sequence, bad flag delimitation and failed FCS. A frame containing errors could be worse to forward than to drop because retransmission could replace corrupted data.

This creates another fork in the evidence. Congestion policing, priority selection and integrity rejection may all increment some notion of loss or discard, but they represent different decisions. The DE cue speaks about preference under congestion. A failed FCS speaks about the validity of the received frame. A policing ratio speaks about traffic outside the contract. Application recovery may react to all three, yet an operator cannot infer the cause from the recovery alone.

The word loss therefore needs provenance. Was the frame never seen at the ingress? Was it classified as excess? Was it eligible but retained? Was it dropped by policy? Was it rejected as corrupt? Did the reverse acknowledgement path fail? Did the transport retransmit? Each answer changes what can be repaired and who controls the repair.

Terminology was not a benchmark result

RFC 3133 was published in June 2001 as an Informational product of the IETF's Benchmarking Methodology Working Group. It extended RFCs 1242, 1944 and 2285 and drew on Frame Relay Forum and Frame Relay MIB terminology. It described terms and formulas, not a named laboratory run.

That status bounds the historical claim. The RFC does not prove that a carrier implemented its classifications, that equipment exposed every required counter, that an SLA used the ratios faithfully or that a customer obtained acceptable performance. The final working-group draft documents the text's lineage, not deployment.

Related documents fill adjacent roles. RFC 1944, RFC 2544 and RFC 2889 concern benchmarking methodology. RFC 2761 supplies ATM benchmarking context relevant to interworking. RFC 2954 defines Frame Relay service managed objects. RFC 6349 later considers TCP throughput testing. None turns RFC 3133's terminology into evidence that a particular service worked.

The document's lasting strength is smaller and more durable. It put a warning label inside a metric: the measured layer can succeed on its own terms while the dependent layer fails on different terms.

From percentage to evidence ladder

A trustworthy operational record would preserve the ratio and then refuse to stop there. It would identify the access channel, DLCI, direction, interval, CIR, Bc, Be and Tc; record offered and delivered frames and payload octets; keep committed and excess populations separate; retain DE, policing, error and discard reasons; and describe the exact measurement points.

Then it would move upward. Which acknowledgement or control frame was lost? Which transport state depended on it? How many bytes and frames were retransmitted? Did the recovery use a later acknowledgement or a timer? How long did the operation take? Did the application complete? What did the user actually observe?

No later field should be synthesized from the earlier percentage. A good DDR is evidence for delivered payload octets under its stated scope. A good Frame Delivery Ratio is evidence for frames. Neither is a receipt for application completion, contractual satisfaction or human experience.

RFC 3133 arrived from an era of virtual circuits, T1s and explicit burst contracts. Its central warning survived that setting. Modern systems still produce dashboards whose greenest number counts the cheapest observable. The dangerous moment comes when the institution forgets that the number was a projection and begins treating it as the service itself.

The acknowledgement in RFC 3133 was tiny. Its historical importance was not. It showed that consequence does not scale with byte count—and that a measurement earns trust not by being broad, but by declaring exactly where its authority ends.

The Delivery Ratio Looked Good. The Application Performed Badly: RFC 3133

Why it matters

Summary

The numerator won; the user lost

A physical rate was not a service promise

The metric lived in one direction of one circuit

One control frame could outweigh its size

Delay averages had a missing population too

A dropped frame could be the correct outcome

Terminology was not a benchmark result

From percentage to evidence ladder

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing