Summary
- RFC 9946 authenticates protocol messages and bounds a UDP capacity test; it does not authenticate a commercial claim about the path.
- A measured value is evidence about a defined test configuration and interval. Capacity planning, liability and service outcome remain local decisions.
An HMAC can establish something important without establishing everything that an operations dashboard may wish it established. In UDPSTP's required authenticated control mode, a participant uses configured key material, a derived authentication key and a freshness window around a timestamp to decide whether to accept a setup or activation message. That is a disciplined answer to a narrow question: should this protocol exchange proceed under this test relationship?
It is not an answer to “who owns the path?”, “what capacity is owed?”, or “did an application receive a promised service?” RFC 9946 specifies the UDP Speed Test Protocol for One-Way IP Capacity measurement. The result belongs to an active experiment with endpoint roles, packet size, time interval, feedback behaviour and local configuration. The cryptographic check protects the exchange. It does not attach a universal institutional meaning to the number produced by the exchange.
The protocol's design makes the limit visible. UDPSTP sends bulk load in one direction and uses Status PDUs in the other direction to control the sender’s rate in near real time. Sequence anomalies or delay variation can indicate congestion; timeouts stop a test if load or feedback stops. This feedback loop is deliberately a measurement mechanism. RFC 9946 says its load-rate adjustment algorithm must not be used as a general congestion-control algorithm, and it confines the method to diagnostic and operations measurement.
That distinction protects more than terminology. Active capacity measurement can intentionally congest a bottleneck. On a shared path, the test itself can impair other traffic. RFC 9946 therefore constrains concurrent independent maximum-capacity tests and requires safeguards that reduce load or stop the session when congestion or a loss of connectivity is detected. The protocol describes how to limit a diagnostic disturbance. It does not authorize a party to impose that disturbance beyond the scope it controls.
Fixed-rate testing draws the governance line even more sharply. It is reserved for operation and maintenance within a locally managed network domain, where an operator is already certain of the IP-layer capacity being validated. A consumer must not be able to initiate it. Where a subscriber asks for a diagnostic test, the specification recommends adjustment precisely because the bottleneck is not known with certainty. A fixed rate is therefore not a button that converts doubt into authority; it is a constrained local tool for a known operational context.
The right record has two columns. The measurement column retains endpoint roles, security mode, request parameters, time window, sequence and delay conditions, rate changes, termination reason and the reported metric. The decision column records who interprets that evidence, which local assumptions apply, what other signals were considered and what action, if any, follows. Blending the columns makes a test report look like a mandate. Keeping them separate leaves the result contestable and useful.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

