Summary
- The STAMP Reflected Test Packet Control TLV lets a sender request the size, number and spacing of replies, while the reflector must protect its path and resources with MTU, data-rate and total-volume limits.
- The same C flag covers an egress-MTU constraint and a rate-or-volume constraint. A sender can infer the broad branch from packet length, but operational accountability needs a reflection-limit receipt that binds the flag to the actual policy, exact cause and measurement consequence.
The sender asked for a train and received one packet. The response was authenticated, the sequence number was plausible, and the C flag was set. Nothing in that compact result says whether the requested packet would not fit on the return interface, whether the requested rate crossed a local ceiling, or whether the accumulated payload would have exceeded a volume allowance. More importantly, it does not say whether the surviving packet is enough for the decision the test was meant to support.
That is not an argument against a one-bit signal. It is the reason to define the evidence that must live beside it.
draft-ietf-ippm-asymmetrical-pkts-14 extends the Simple Two-Way Active Measurement Protocol, or STAMP, for asymmetric replies. Ordinary STAMP is symmetrical in the relevant sense: the reflector returns one packet for one packet, and the sizes correspond. The proposed Reflected Test Packet Control TLV lets a Session-Sender request a different reflected length, more than one reflected packet, and a nanosecond interval between consecutive packets. The mechanism is useful for modelling asymmetric application traffic, rate measurement and multicast observation. It also turns a small request into a potential instruction to emit substantially more traffic.
The draft addresses that power directly. A supporting Session-Reflector must impose limits on reflected data rate and total STAMP payload volume. The extension must be administratively controllable and disabled by default. Identity protection is mandatory, authenticated STAMP or its HMAC TLV is recommended, and multicast use begins conservatively because one request can reach many reflectors.
The control is real. The record of how it acted is thinner.
One flag represents two different constraints
The response-length calculation comes first. A reflected packet must be large enough for the applicable base packet and extension material, excluding received Extra Padding, and large enough for the sender’s requested length after four-octet alignment. Extra Padding supplies the difference when the requested shape is longer.
If that calculated packet exceeds the maximum transmission unit of the egress interface back toward the Session-Sender, the reflector sets C to one and sends a single packet equal in length to that MTU. The requested train has become one shorter response.
The second branch is independent of packet fit. A reflector must test the requested behavior against both a data-rate limit and a total-volume limit. If either would be exceeded, it again sets C to one and sends a single packet. In this branch the packet keeps the otherwise calculated length. The requested train has become one reply because the local protection policy refused the requested load, not because that one packet could not fit.
The draft gives the sender a practical inference. If the returned packet is shorter than the requested length, the egress MTU is the likely branch. If it equals the requested length, the rate and/or volume limit is the likely branch. This is valuable. It prevents the bit from being wholly opaque.
It is still not a policy receipt. Equality does not distinguish rate from volume. It does not reveal the threshold, time window, burst treatment, concurrent-session accounting, configuration version or operator that set the limit. A shorter packet identifies the broad MTU branch but does not preserve when and where that MTU was observed or whether the return path later changed. The inference describes packet behavior; it does not recreate the decision environment.
A constrained response is not the requested experiment
Suppose the test was designed to observe a burst of several reflected packets at a specific spacing. One packet can prove that a reflector received and processed the request. It can carry timestamps and extension data. It cannot reproduce the requested burst. A tool that labels both outcomes “test completed” would collapse protocol completion into experimental equivalence.
The same distinction applies to rate measurement. The draft provides controls for response length, count and interval, but expressly leaves the access-rate metric and measurement method outside its scope. Its operational section distinguishes out-of-service testing, where high load may deliberately create congestion at a bottleneck, from in-service testing, which should start low and increase gradually. It warns that extensive measurement can violate limits imposed by a service provider.
The C flag therefore cannot be read as a capacity result. A rate or volume policy may have acted before the requested load was emitted. An MTU constraint may have changed the packet shape. In multicast, selection or fan-out control may have changed which reflectors answered. Each is a legitimate safety action. Each changes the evidence available to the analyst.
There is a further risk of circular interpretation. In-service probe traffic can contribute to the congestion it is measuring. ECN Congestion Experienced marking indicates incipient congestion, but the threshold for “significant” congestion and the operational response remain deployment-specific. If a test is reduced by one local policy while its remaining traffic helps trigger another signal, the final dashboard needs to preserve both events rather than presenting one unexplained red or green state.
Multicast makes the hidden denominator larger
For multicast measurement, a Session-Sender can be the root while Session-Reflectors occupy leaves of a distribution tree. One control packet may provoke many replies toward one endpoint. The draft offers Layer 2 and Layer 3 Address Group sub-TLVs to select subsets of reflectors. It gives examples such as probabilistic selection by an address mask or selection by an IP prefix.
Those examples solve an emission problem, not a census problem. A received sample cannot by itself prove how many eligible reflectors existed, which ones received the request, which selector an in-path system applied, or which local limits suppressed responses. “Eight replies” has no stable denominator until the selection and policy context travels with the observation.
The draft even allows a multicast environment, depending on its implementation, to reduce replies by modifying the group-selection fields it sees. With integrity protection, an in-path change will fail verification unless the modifying element is inside the trust boundary and can recompute the protection. That boundary matters. A valid packet after a trusted modification shows cryptographic continuity from the last protected state; it does not, on its own, tell an analyst who authorized the modification or what the pre-modification request contained.
This is exactly where a governance record should be additive rather than obstructive. The packet format need not become a change-management database. The operator needs a joined record that can explain why a safe, authenticated exchange produced evidence different from what the sender originally requested.
Preserve the policy generation, not only the flag
A reflection-limit provenance receipt should begin with the session identity: sender and reflector, transport, STAMP mode, authentication or HMAC profile, sequence evidence, and the software and configuration generations at both ends. It should retain the requested length, count and interval exactly as sent, together with address-group selectors and any return-path instruction.
Next comes purpose. Was the test in service or out of service? What measurement method and service objective justified the requested envelope? Which traffic, users or maintenance window were protected? A packet request can be syntactically valid while being inappropriate for the live context.
The reflector side should record the active egress interface, relevant MTU observation, data-rate ceiling, total-volume ceiling, units, accounting window, burst rule, concurrent-session treatment and policy version. The public or cross-team record may hash or redact commercially sensitive values, but the decision owner must be able to reproduce which policy applied.
The outcome should name the branch. “MTU” is different from “rate”, “volume”, or “rate and volume”. Record the returned count and length, C and U values, any ECN observation, and whether multicast selection was modified by a trusted element. If the sender only inferred the branch from packet length, label it as inference. Do not upgrade inference into reflector attestation.
Finally, state the measurement consequence. The response may be usable for a narrow reachability or timestamp observation while being insufficient for the intended burst or rate calculation. It may require a lower request, a different maintenance window or an out-of-service run. It may be discarded because the denominator is unknowable. The reviewer, expiry, exception, correction history and rollback authority complete the receipt.
The receipt is deliberately off wire. It is not a new STAMP field, an IANA action or a demand that every operator reveal thresholds. It is a way to prevent three substitutions: a protected response for the requested response, protocol success for measurement validity, and one current configuration for the policy that acted at the time.
Other flags must not be recruited as explanations
The draft keeps several nearby outcomes separate. If a sender requests zero reflected packets, the reflector sends none and should discard the request, although local policy may specify another handling. When no reply is the actual intent, the Return Path Control Code mechanism is preferred. That is not the C-flag path.
The U flag also carries different information. A contradictory combination with a “No Reply Requested” return-path control produces U and an operator notification. A non-monotonically increasing sequence number can produce a single U-marked response as replay protection. The document cautions that the sequence observation may instead result from reordering or duplication. U is not a spare reason code for the local reflection limit, and a non-monotonic number is not proof of an attacker.
Likewise, authentication is not authorization to consume any volume at any rate. It protects identity and integrity. The administrative enablement, trusted-sender policy, reflection envelope and operational purpose remain separate decisions. Combining them only in a dashboard status would make later review depend on whichever configuration happens to be live then.
Sources
- Current document record
- Document history
- Revision 14 in HTML
- Revision 14 in text
- Revision 14 source XML
- Revision 13 in text
- Official revision 13–14 comparison
- IPPM Working Group
- IPPM documents
- RFC 8762: STAMP
- RFC 8972: STAMP optional extensions
- RFC 9097: UDP speed test
- RFC 7497: rate measurement problem statement
- RFC 9503: STAMP return-path control
- RFC 8085: UDP usage guidelines
- RFC 1982: serial number arithmetic
- RFC 7799: active and passive measurement methods
- RFC 7942: implementation status
- Lu Heng: Minimum Initial Specification, Localized Future Decision
- Lu Heng: The Policy Mirror
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
