Summary

  • RFC 10052 adds a control TLV that can request a reflected packet length, packet count and interval, allowing one STAMP request to produce an asymmetric response train.
  • The C flag reports two bounded reflector exceptions—an egress MTU limit or a local response-rate/volume limit. It does not report end-to-end delivery, path equivalence, capacity or application success.
  • A probe can more closely approximate selected application traffic characteristics without becoming representative evidence of the application, its users or its outcome.

An operator asks for eight reflected packets, each a particular size and separated by a specified number of nanoseconds. Eight arrive. The cleanest operational sentence is also the narrowest: this collector observed eight packets from this STAMP exchange under these conditions.

The tempting sentence is much larger: the application can sustain the same rate. RFC 10052, published in September 2026, does not grant that inference. Its optional extension gives a Session-Sender control over the shape requested from a Session-Reflector. The abstract says different lengths or additional responses can better approximate application traffic conditions. Approximation is a design aid, not an identity claim.

That difference is where measurement programmes either preserve evidence or manufacture confidence.

A packet train begins as an instruction

The new Reflected Test Packet Control TLV, allocated as type 12 in the IANA STAMP registry, carries three main values: reflected-packet length, number of reflected packets and interval between consecutive reflected packets. RFC 8762 supplies the base STAMP exchange; RFC 8972 supplies the optional TLV architecture in which the new control travels.

Each value is a request before it is anything else. The reflector must first calculate a legal response length. It takes the larger of the protocol minimum and the requested length rounded to a four-octet boundary. If that size exceeds the outgoing interface's MTU, it returns one MTU-sized packet rather than the requested train.

The count is conditional too. A supporting reflector must enforce local ceilings for response data rate and total data volume. A request that crosses either ceiling yields one packet, not the requested number. A request for zero ordinarily yields no reply, although local policy may override that default; the RFC recommends the dedicated Return Path no-reply mechanism when silence is the real intention.

So the control surface is not a remote command that compels arbitrary traffic. It is an instruction evaluated by a local implementation under protocol minimums, interface constraints and operator policy. That is a healthy boundary. It also means a dashboard must not present “requested eight” as “sent eight” before the reflector supplies a receipt.

The C bit is not a green light

RFC 10052 gives the sender one compact handling signal. IANA assigns bit position 3 to the C flag, labelled Conformant. The sender transmits that bit as zero. The reflector sets it to one when either the requested packet length exceeds its egress MTU or the requested response rate or volume exceeds its configured limits. In the ordinary case it leaves C at zero in each reply.

The two C=1 cases can be distinguished by packet length. A reply shorter than requested points to the MTU case. A reply equal to the requested length points to the local rate or volume ceiling. This is useful, deterministic information about why the reflector reduced the response to one packet.

It is not a verdict on the rest of the system. C=0 does not say that every reflected packet reached the collector. C=1 does not say the path lacked capacity. Neither value says the production application used the same five-tuple, policy class, route, queue, payload distribution or timing. The bit closes one question about reflector construction; it does not close the measurement case.

Lu Heng's essay on reality layers is useful precisely because the layers here are easy to name. The TLV is an instruction. The C bit is a local protocol statement. An interface counter is an emission receipt. A packet capture is an observation. Application telemetry is an application receipt. A user or business outcome is another reality again. None becomes the next simply by appearing in the same dashboard.

Receipt Safe conclusion Unsupported promotion
Requested count, length and interval The sender asked for this shape The reflector emitted it
C flag One of two defined exceptions was or was not invoked The path passed a capacity test
Reflector transmit counter The implementation recorded local emission The collector received every packet
Collector capture This endpoint observed this packet train The application saw equivalent conditions
Application telemetry A named workload behaved this way Every workload or path will behave this way
User outcome A defined cohort reported or exhibited an effect The STAMP mechanism alone caused it

The RFC supplies a control, not the metric

Section 4.1 of RFC 10052 is unusually important for leadership reporting: the access-rate metric and the method for measuring it are outside the document's scope. The extension satisfies control requirements identified in RFC 7497—asymmetric packet size, number and rate—but a method still has to define what is measured, where endpoints sit, how background traffic is handled and how results are interpreted.

That older requirements document also warns that test traffic may receive different treatment from user traffic when its packet characteristics differ. Active testing can perturb the network, skew its own result and introduce congestion. RFC 7799 classifies active methods by the dedicated traffic they generate; the generation is part of the experiment, not a neutral window onto an untouched system.

RFC 9097 and the newer RFC 9946 define separate capacity-measurement machinery and operational cautions. They discuss load adjustment, endpoint placement, competing traffic and the possibility that the test reduces the throughput it is trying to characterize. The presence of those methods prevents a convenient shortcut: a response train is an input to measurement, not a self-authenticating capacity number.

Multicast selection is not a sample of experience

The extension also addresses multicast. One request at the root can produce replies from many leaf reflectors. Layer 2 and Layer 3 Address Group sub-TLVs can narrow who responds: by a masked hardware address, by an IPv4 or IPv6 prefix, or by another deterministic match. The RFC offers a one-in-sixteen mask example and a vendor-prefix example.

Those rules reduce load; they do not create a representative population. “One in sixteen addresses matched” is not the same statement as “one in sixteen users were randomly sampled.” Hardware assignment, topology, vendor concentration and address planning can correlate with the very conditions under study. A selected address group must therefore be described as the set the rule selected, not as a proxy for customers unless an independent sampling design supports that claim.

The risk is physical as well as statistical. Multicast replication can amplify one probe across a distribution tree. RFC 10052 requires bounded rate control, tells senders to begin conservatively with a single reflected packet, and requires reflector support for the TLV to be administratively controllable and disabled by default. Spoofed requests can become denial-of-service traffic, so the document requires identity protection and recommends authenticated STAMP or the HMAC TLV. RFC 8085 supplies the wider UDP load discipline.

A collector does not erase the return path

Combined with the Return Path extensions in RFC 9503, reflected packets can be sent to a measurement collector rather than back to the sender. The LMAP framework gives those measurement roles a common architecture. This is operationally useful: a test packet might follow the forward path of a video stream while replies go elsewhere for analysis.

But the example exposes the boundary. Sharing one direction with a camera stream does not prove the test shared every forwarding decision, queue treatment or transient state with the video. Sending replies to a collector deliberately creates a different return destination. The collector can prove what it observed, with its clock and vantage point. It cannot retroactively turn that observation into an application trace.

The Datatracker record and draft history establish how the specification reached publication; the September activity report establishes its place in the month's standards output. The RFC Editor's current record, plain text and XML preserve the normative details. None is a deployment census.

Lu Heng's running-code primacy supplies the final discipline: a specification becomes operational evidence through a named implementation, configuration and observed result. His minimum initial specification explains why the RFC's narrowness is a strength. It defines a deterministic control surface and leaves metric choice, thresholds and adoption to real deployments. His account of the agency problem adds the governance question: who chose the probe shape, reflector limit, address group, collector and interpretation?

Eight packets can be excellent evidence. The discipline is to say what they are evidence of.

Sources