Summary

  • RFC 5357 gives the Session-Reflector two timestamp duties: record the best approximation of packet arrival, then record the best approximation of response departure. Their difference exposes time spent inside the reflector. The returned packet carries this evidence to the Session-Sender, which owns collection and calculation.
  • The reflector does not keep packet-level measurement records, TWAMP has no Fetch-Client, and the sender's scheduling and recording implementation are outside the base standard. A reflected packet is therefore an evidence transfer, not a complete or centrally retained performance verdict.
  • Control acceptance, test-packet transmission, reflector validation, timestamp quality, metric calculation, production-flow association, operational decision and observed service outcome require separate receipts. Protected mode authenticates protocol material; it does not authenticate the conclusion drawn from the resulting number.

The archive is deliberately empty at the far end

OWAMP provides roles for one-way testing and retrieval. TWAMP changes that custody model. Its Session-Reflector receives a packet and creates another packet in response, but it does not collect the packet information for later fetching. The Fetch-Client role disappears, and the Fetch-Session command is not used.

The absence is not missing functionality to be inferred away. It defines where the measurement record lives. The reflector returns the sender's sequence and timestamp material, adds its own receive and transmit observations, and places the evidence back in the hands of the Session-Sender.

That choice simplifies the remote role, but it makes provenance at the sender more important. If the sender stores only a final latency value, it has discarded the material that could explain packet identity, reflector residence, clock error, TTL observation and loss handling.

The durable record should retain the returned fields, the negotiated session context and the calculation version. A dashboard number without those joins is a conclusion separated from its evidence.

Two reflector timestamps remove one component, not every uncertainty

The reflector timestamps a packet when it arrives and again immediately before it sends the response. The difference between those values is the elapsed time inside the reflector. Subtracting that interval can prevent remote processing delay from being mistaken for network round-trip delay.

Both reflector timestamps use the same reflector clock, and the reflector Error Estimate applies to them. The sender has its own departure and return observations. This architecture avoids requiring synchronization between the two hosts for a round-trip calculation.

Yet removal of one component is not removal of every uncertainty. Timestamp approximation, clock quality, local scheduling, queueing, packet treatment and the selected sample still matter. The error fields are evidence that the specification expects bounded imperfection, not ornamental metadata.

The correct claim is narrow: the packet contains enough information to identify reflector residence time within the quality expressed by the timestamps. It does not prove a synchronized global timeline or exact one-way path delays.

The sender owns the calculation that the standard does not prescribe

RFC 5357 says the Session-Sender collects and records the information needed for two-way metrics. How it schedules sends and how it records returned packets are implementation dependent. The send schedule is not communicated to the reflector.

This division separates the wire contract from the analytical contract. The protocol defines fields and behaviors needed to transport observations. It does not choose the sample window, missing-packet rule, aggregation, outlier policy, confidence model or alert threshold for an operator.

Two systems can exchange conforming packets and calculate different summaries from the same raw record. One may report a median, another a tail percentile, and a third may discard samples under a quality rule. Protocol conformance alone cannot select among them.

The measurement ledger therefore needs the raw sample, calculation code or version, inclusion rules, window boundaries and output. Otherwise the number cannot be reproduced even when every packet was valid.

Control acceptance is only permission to begin

TWAMP-Control establishes roles over a TCP connection, negotiates modes, requests sessions, starts testing and stops it. A Server may accept a requested session, confirm a port or suggest an alternate port when the requested one is unavailable.

An Accept value of zero confirms a control-plane decision. It does not prove that the Session-Sender transmitted a packet, that the path carried it, that the reflector processed it, that a response returned or that the sender calculated a metric.

Likewise, a Start-Sessions acknowledgement marks a lifecycle transition, not a successful sample. Treating it as measurement success would let a control receipt borrow evidence from a data plane that has not yet run.

Records should join the control connection, negotiated mode, requested and accepted addresses and ports, DSCP, timeout, start state and each test exchange without collapsing them into one green status.

One UDP port improves correlation but does not prove a path

The Session-Sender uses the same UDP port to send and receive within a session. The Session-Reflector also sends from the port on which it receives the test packets. This makes the exchange easier to associate with one session and can preserve the expected transport tuple.

The tuple does not prove that forward and reverse packets traversed the same network path. Routing, hashing, policy and failures can remain directional. Nor does it prove that a production flow with different encapsulation or packet fields received the same treatment.

An alternate accepted reflector port is also a negotiated fact, not a failure by itself. The sender must bind subsequent packets and records to the port actually accepted, rather than the first port it requested.

The port receipt answers where the reflector expected the test traffic. It does not answer what every router did or which customer traffic the result represents.

DSCP preservation creates a comparable mark, not identical treatment

The Control-Client may request a DSCP for its control connection. The Server should use the DSCP observed on the incoming SYN, avoiding ambiguity if a device remarked the packet before it arrived. For a test session, the Type-P descriptor's capability is limited to DSCP, and reflected test packets use the same DSCP.

These rules create a visible treatment request and help keep the two test directions comparable. They do not prove that every hop honored the code point, that queues were configured as expected, or that production traffic shared the same classification and resource conditions.

A packet capture at one endpoint shows a field at that endpoint. It does not establish its value across the route. A configuration database shows intent. It does not establish queue behavior under the measured load.

Operational use should bind the requested value, value observed by each endpoint where available, path context, policy configuration and counters. Matching fields are a prerequisite for some comparisons, not the comparison's final result.

Equal payload length removes another avoidable difference

The reflector packet format is larger because it carries the original sender material plus its own observations. RFC 5357 allows the sender to add padding so the IP payload lengths match in both directions. It describes minimum padding of 27 octets in unauthenticated mode and 56 in authenticated or encrypted modes.

Equal length controls one variable that could affect fragmentation, serialization or treatment. It still does not make the two directions identical. Headers, route, load, queues and policies can differ.

The evidence should state whether equalization was used, the resulting packet sizes and whether fragmentation occurred. Otherwise an apparent directional comparison can include a size difference that the protocol provided a way to remove.

Controlled similarity is valuable precisely because it is bounded. Each controlled field should be named; uncontrolled fields should remain visible as uncertainty.

Sender TTL 255 has two meanings

The Session-Sender sets Sender TTL to 255. The reflector should replace that value with the TTL or Hop Limit observed in the received IP header. If the implementation cannot access the incoming field, it must return 255.

Consequently, a returned value of 255 is not unambiguous evidence that no hop decremented the field. It can be a sentinel declaring that the observation was unavailable.

Interpreting 255 as a measured zero-hop path would turn absence of access into a topology claim. The result must preserve whether the reflector read the header or used the required fallback.

Even a lower observed value provides only a bounded endpoint observation. It can support change detection or hop-budget reasoning, but it does not name the route, every intermediate device or the cause of a change.

Stop is a sampling boundary with a tail

When the Control-Client sends Stop-Sessions, the reflector does not necessarily stop at the same instant. It must continue to reflect packets already in transit if they arrive within the negotiated Timeout, and it must ignore packets arriving after that boundary.

The sample therefore has a defined tail. A response after the stop command can still be valid. A packet arriving later can be intentionally absent. Without the timeout and event times, an analyst can misclassify both cases.

REFWAIT governs another lifecycle boundary. A reflector may discontinue an active session after no associated packet arrives for REFWAIT seconds; the default is 900 seconds and may be configurable. This protects resources during sender or path failure.

The test record needs stop time, timeout, last sender departure, reflector arrivals, returned responses, REFWAIT value and session-release event. Loss classification depends on these boundaries.

Protected mode authenticates material, not interpretation

TWAMP-Test provides unauthenticated, authenticated and encrypted modes. In protected modes, the reflector decrypts the relevant portion, checks HMAC-covered material and constructs a protected response. TWAMP-Control also uses HMAC coverage after key establishment.

These controls can establish integrity and configured-key possession within the session. They reduce the risk that an outsider changes protected fields unnoticed.

They do not prove that the selected endpoints represent a production service, that the timestamps are sufficiently accurate for a particular decision, that the route is symmetric or that an operator's threshold is justified.

An authentic sample can be mis-scoped, poorly calculated or over-interpreted. Security receipt and analytical receipt should be joined but never merged.

Error Estimate is part of the value

Sender and reflector timestamps travel with Error Estimate fields. The reflector's estimate also applies to its receive timestamp. This makes quality metadata part of the packet contract.

If a system exports latency while dropping the estimates, it reports more certainty than the protocol supplied. A narrow change near the timestamp error can be operationally indistinguishable from noise even when every packet is authentic.

Aggregation should specify how individual estimates affected inclusion, bounds and alerts. It should also identify clock state changes within the window, because a single summary may otherwise blend samples with different confidence.

The number and its error cannot be separated without changing the claim. The same principle applies to missing samples and sentinel fields.

Reflection creates a resource surface

The reflector responds to each received test packet and keeps session state for active work. Rate, authentication and lifecycle controls therefore matter to resource protection. RFC 5357 also notes that the 32-bit password-derivation iteration Count can be abused to force excessive computation.

Resource controls can alter the observation. A missing response may reflect path loss, input rejection, session expiry, resource exhaustion, policing or sender failure. RFC 5357 does not authorize assigning one cause from absence alone.

The security record should retain negotiated mode, authentication result, request rate, limiter state, session existence and timeout reason. Measurement and protection share infrastructure, so protection events belong in the evidence chain.

This is distinct from claiming that any present loss was caused by rate limiting. The point is to preserve alternatives until evidence selects one.

Later extensions change features, not the original receipt boundary

Subsequent RFCs added mixed security, individual session control, TWAMP Light, a well-known test port, query/response behavior, extended features, simplified control and LAG-member identification.

Those documents show that operational needs evolved. They do not prove that a current endpoint implements every extension, that an option was negotiated, or that an old session can be interpreted under later semantics.

The IANA registry likewise records assigned values. A registry row proves coordination over a code point, not support, configuration, execution or service result.

The RFC Editor errata snapshot captured for this article lists six Verified, seven Held for Document Update and one Rejected report. That state must be read alongside the original document; it is not permission to silently rewrite historical text or assume every implementation follows a correction.