Summary

  • RFC 9971’s MLRsearch describes data-plane trials through declared loads, durations, loss goals and bounds; it does not define a universal performance verdict.
  • A result becomes comparable only with its traffic profile, search-goal configuration, deviations and report; a bare number cannot become an SLA, an application result or a deployment claim.

A number has a perimeter

Maciek Konstantynowicz and Vratko Polak’s RFC 9971, Multiple Loss Ratio Search, addresses a familiar problem in software-network testing. Binary search can be slow; trial outcomes can be noisy; a zero-loss throughput rule can be difficult to interpret when successive trials disagree. The RFC offers a methodology that can search more than one loss-ratio goal and make a test report carry the terms needed to understand the result.

That is a substantial improvement in measurement discipline. It is not a declaration that a device, a network or a service has a single inherent “throughput” that the method has finally uncovered. The result has the perimeter of the System Under Test, the traffic profile, the trial input, the selected goals and the reporting choices. Crossing that perimeter requires new evidence.

The manager, controller and measurer do different work

RFC 9971 models three functions. The Measurer runs trials. The Controller selects loads and durations. The Manager preconfigures the involved entities and produces the Test Report. A trial returns a bounded observation: for example, loss at a particular input frame rate. A Trial Output includes loss ratio, effective duration and forwarding rate; a Trial Result combines the input and output.

Those definitions protect against a common sales-room shortcut. A trial forwarding rate is not automatically an application’s goodput. A low trial loss ratio is not automatically low latency. Neither is a proof that routing was correct, that a failure will be recovered, that a tenant receives the same outcome, or that the measurement corresponds to a commercial commitment. Each of those propositions has another control surface and another receipt.

Multiple goals expose a choice rather than hiding it

The method permits multiple Search Goals, commonly with different Goal Loss Ratios. It also uses parameters such as Goal Final Trial Duration, Goal Duration Sum, Goal Exceed Ratio and Goal Width. They decide what duration is sufficient, how much high-loss trial time may be tolerated at a lower bound and how close the relevant upper and lower bounds must become.

There is no universal configuration in the RFC. Goal selection is left to the test-procedure operator or future documents; a Controller’s internal load-selection heuristics are implementation-specific. That flexibility can characterize a system more carefully, but it also means two labs cannot establish comparability merely by both saying “MLRsearch.” They need to disclose the configuration that made their answers mean the same thing.

Noise is information, not permission to erase it

RFC 9971 explicitly discusses inconsistent trials: the same load may produce different loss ratios, and a higher load can even produce a lower loss ratio. Its use of relevant upper and lower bounds gives the procedure a conservative way to work with such observations. It does not erase the underlying fact that the measurement varied.

The report should therefore preserve the bounds, the duration logic, the traffic profile, relevant warm-up and any deviation from RFC 2544 trial practice. RFC 9971 allows deviations, but requires that they be stated explicitly; it warns that deviation weakens comparability. A short, repeatable search can be useful. It is not the same claim as an RFC 2544-compliant throughput result unless its configuration actually meets that separate methodology.

The useful receipt

For an operator, buyer or reviewer, the practical receipt has at least five parts: the exact SUT and configuration; traffic profile and offered-load definition; every Search Goal and its duration, loss, exceed and width settings; the relevant upper and lower bounds; and the deviations, repetitions and uncertainty visible in the test report. A production service assessment then adds its own evidence: live demand mix, path variation, latency, failure behaviour, recovery, policy and the contractual metric being promised.

Konstantynowicz’s contribution is most valuable when kept this exact. MLRsearch turns a fuzzy performance claim into a more inspectable laboratory result. It does not let the laboratory result speak for systems it did not test.

Sources