A Protocol for Periodic On-path Explicit Measurement

A Protocol for Periodic On-path Explicit Measurement Ericsson

marcus.ihlar@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com

Web and Internet Transport SCONE measurement loss on-path This document defines the Periodic On-path Explicit Measurement (POEM) protocol, which enables passive on-path measurement of packet loss for QUIC flows. POEM uses periodic marker packets, coalesced with ordinary QUIC packets, that allow on-path network elements to measure upstream packet loss by counting packets between markers. Marker packets also carry a sender-reported loss count, enabling observers to distinguish upstream from downstream loss. Additionally, POEM defines a report mechanism through which network elements communicate measurement results back to endpoints. About This Document Status information for this document may be found at . Discussion of this document takes place on the SCONE Working Group mailing list (), which is archived at . Subscribe at .

Introduction Packet loss is an important metric for network operations. Detecting, measuring, and localizing loss helps maintain quality of service and resolve performance issues. QUIC encrypts its transport headers, making passive observation of loss through protocol fields impossible. Unlike TCP, where sequence numbers and acknowledgments are visible to on-path observers, QUIC provides no equivalent signal. As QUIC's share of Internet traffic grows, this limits the ability of network operators to measure loss. Explicit measurement techniques have been proposed to address this, where endpoints cooperate by exposing measurement signals in the clear portion of packets. The Explicit Flow Measurement Protocol defines a per-packet signaling approach based on the Alternate-Marking method , where a square signal bit (Q) and a loss event bit (L) are set on every packet. This requires measurement headers on every packet in the flow. This document defines the Periodic On-path Explicit Measurement (POEM) protocol. Instead of per-packet signals, POEM uses periodic marker packets that delineate measurement intervals. On-path observers count packets between markers to estimate upstream loss, while the marker carries a sender-reported loss count enabling end-to-end and downstream loss estimation. POEM also defines a report mechanism where network elements write measurement results into dedicated report packets, allowing endpoints to observe where on the path loss is occurring. Like the SCONE protocol , POEM uses QUIC long header packets coalesced with ordinary QUIC packets and relies on on-path network elements that can read and modify packet fields. Because POEM only requires a packet in a small fraction of datagrams, the remaining datagrams are available for other coalesced signals such as SCONE.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

Marker packet:: A POEM packet sent by an endpoint at a fixed interval that delineates measurement periods.
Report packet:: A POEM packet sent by an endpoint that an on-path network element can update with measurement information.
Observer:: An on-path network element that counts packets and/or writes measurement information into report packets.
Upstream loss:: Packet loss occurring between the sender and the observer.
Downstream loss:: Packet loss occurring between the observer and the receiver.

Protocol Overview POEM operates alongside QUIC connections. Endpoints negotiate POEM support using a QUIC transport parameter (). Once negotiated, endpoints periodically send marker packets coalesced with ordinary QUIC packets. Marker packets are sent once every 64 packets. The marker carries:

A 1-bit alternating counter to detect marker loss.
A 5-bit loss count reporting lost packets detected by the sender since the previous marker.

On-path observers detect marker packets by their version field and count packets transiting the flow (identified by the UDP 4-tuple) between consecutive markers. A count less than 64 indicates upstream loss. The observer can estimate downstream loss by subtracting its upstream loss count from the sender's reported loss count, which represents total end-to-end loss. Endpoints can also send report packets at a lower cadence. An observer writes a 6-bit value into the report packet indicating the fraction of observed loss that is upstream of its position. shows the basic operation of POEM.

Marker Packets

Marker Packet Format A marker packet is a QUIC long header packet that follows the QUIC invariants; see . shows the format of the marker packet.

Marker Packet Format The fields are defined as follows:

Header Form:: The most significant bit (0x80) is set to 1, indicating a QUIC long header packet.
Reserved:: The next bit (0x40) is reserved and can be set according to .
Counter:: A 1-bit alternating counter (0x20). The sender toggles this bit with each successive marker packet. This allows observers to detect lost markers and aids synchronization for observers joining mid-flow.
Loss Count:: A 5-bit unsigned integer (0x1f) indicating the number of packets that the sender has detected as lost since the previous marker packet was sent. The value saturates at 31; if more than 31 losses are detected in a single interval, the sender reports 31.
Version:: A 32-bit version field set to 0xTBD1, identifying this as a POEM marker packet.
Destination Connection ID Length and Destination Connection ID:: Set to the same value as other packets in the same datagram; see .
Source Connection ID Length and Source Connection ID:: Set to match the Source Connection ID field of the packet that follows in the datagram. If the following packet has a short header, this field is empty and the length is set to 0.

Marker packets MUST be coalesced with other QUIC packets and MUST be the first packet in the UDP datagram. A sender MUST NOT include more than one marker packet in a datagram.

Marker Interval The marker interval is fixed at 64 packets. After sending a marker, the sender counts 63 additional packets (including the QUIC packet coalesced with the marker) and then sends the next marker. For the purpose of POEM, a packet is a single UDP datagram. Observers count UDP datagrams on the 4-tuple regardless of how many QUIC packets are coalesced within each datagram. The value 64 balances measurement granularity against overhead: markers constitute less than 2% of total packets while individual intervals yield useful loss counts at typical loss rates.

Sender Loss Count Semantics The sender maintains an Unreported Loss counter, as defined in , that persists across marker intervals. Unlike , where the counter state is signaled as a single bit per packet, POEM reports the counter value directly in the marker's loss count field. The counter is incremented each time QUIC's loss detection declares a packet lost. If the implementation later determines that a previously declared loss was spurious (e.g., a late acknowledgment confirms delivery), the counter is decremented, which may cause it to become negative. When constructing a marker packet, the sender sets the loss count field to min(Unreported_Loss_counter, 31) if the counter is positive, or to 0 otherwise. The sender then subtracts the reported value from the counter. Spurious detections that drive the counter negative are compensated by absorbing subsequent real losses until the counter returns to positive. Observers MUST treat a loss count of 31 as "at least 31 losses."

Sending Marker Packets POEM packets can only be sent once both endpoints have exchanged the poem_supported transport parameter (). This means the first POEM packet cannot be coalesced with the Initial packets of a QUIC handshake. A sender that has negotiated POEM support proceeds as follows:

Maintain a packet counter, initialized to 0 after each marker.
Maintain an Unreported Loss counter (persistent across markers), initialized to 0 at connection start. Increment on each loss declaration; decrement on each spurious loss detection. The counter may become negative.
After sending 63 packets following the previous marker, construct the next marker packet:
- Toggle the counter bit.
- Set the loss count field to min(Unreported_Loss_counter, 31) if positive, or 0 otherwise.
- Subtract the reported value from the Unreported Loss counter.
- Reset the packet counter.
Coalesce the marker packet as the first packet in the next UDP datagram, followed by one or more QUIC packets.

A sender SHOULD include a marker packet in one of the first few datagrams sent after negotiation completes to allow observers to begin measurement early.

Observing Marker Packets An observer identifies marker packets by the long header bit (0x80) in the first byte and the version field 0xTBD1. An observer begins counting packets for a flow upon observing the first marker on that 4-tuple. No measurement is possible until the second marker is observed, at which point the first interval count is available. This applies both to flows observed from the start and to flows detected mid-way. When an observer detects a marker packet, it:

Records the current packet count for the flow (identified by the UDP 4-tuple) since and including the previous marker.
Reads the counter bit to detect marker loss. If the counter bit is the same as the previous marker's counter bit, one marker was lost (and the observer should treat the interval as spanning two marker periods).
Reads the loss count field, which indicates the sender's observed end-to-end loss for the preceding interval.
Computes upstream loss for the interval as: upstream_loss = N - observed_packet_count, where N is 64 (or 128 if a lost marker was detected).
Forwards the marker packet unmodified.

The observer does not modify marker packets.

Receiving Marker Packets The receiver reads the marker packet to obtain:

The counter bit, to detect marker loss.
The loss count, indicating the sender's reported losses.

The receiver MAY use this information for its own diagnostics or relay it to the application layer. A marker packet MUST be discarded (its contents ignored) unless another QUIC packet in the same datagram is successfully processed.

Connection Migration When a QUIC connection migrates to a new path (new UDP 4-tuple), the sender MUST reset its packet counter and MUST reset the Unreported Loss counter. Carrying loss state across paths would both produce meaningless measurements and risk linking the new path to the previous one. A sender SHOULD send a marker in one of the first datagrams on the new path. Observers track state per 4-tuple and therefore start fresh on the new path.

Report Packets

Report Packet Format A report packet is a QUIC long header packet that an on-path network element can update with measurement information for the receiving endpoint. shows the format of the report packet.

Report Packet Format The fields are defined as follows:

Header Form:: Set to 1 (0x80), indicating a QUIC long header packet.
Reserved:: The next bit (0x40) is reserved and can be set according to .
Upstream Ratio:: A 6-bit unsigned integer (0x3f) representing the fraction of total observed loss that occurred upstream of the observer. The value 63 is reserved to indicate that no observer has written a value. When sent by the endpoint, this field MUST be set to 63. An observer overwrites the field with a value between 0 and 62, where 0 means all observed loss is downstream and 62 means all observed loss is upstream. Intermediate values represent proportional fractions (value/62).
Version:: A 32-bit version field set to 0xTBD2, identifying this as a POEM report packet.
Destination Connection ID and Source Connection ID:: Same rules as for marker packets ().

Report packets MUST be coalesced with other QUIC packets and MUST be the first packet in the UDP datagram.

Upstream Ratio Semantics The upstream ratio encodes the observer's estimate of what fraction of total path loss occurs upstream of its position. The value 63 indicates that no observer wrote a measurement. Values 0 through 62 represent the observer's estimate, where 0 means all loss is downstream and 62 means all loss is upstream. The receiving endpoint combines this with its own end-to-end loss estimate (from acknowledgment processing) to determine approximate upstream and downstream loss rates. For example, if the endpoint measures 3% end-to-end loss and receives an upstream ratio of 21 (approximately 1/3), it can infer roughly 1% upstream loss and 2% downstream loss relative to the observer.

Sending Report Packets Report packets SHOULD be sent less frequently than marker packets. A rate of one report every 4 to 8 marker intervals (every 256 to 512 packets) is RECOMMENDED. The precise cadence is a sender decision. When sending a report packet, the sender sets the upstream ratio field to 63 and coalesces the report as the first packet in the UDP datagram. A sender MUST NOT send both a marker packet and a report packet in the same datagram.

Observing Report Packets An observer identifies report packets by the long header bit (0x80) in the first byte and the version field 0xTBD2. When an observer detects a report packet, it MAY write measurement information into the upstream ratio field:

Compute the upstream loss rate from recent marker intervals.
Compute the total loss rate from the sender's reported loss counts over the same intervals.
If total loss is non-zero, compute: upstream_ratio = (upstream_loss / total_loss) * 62, clamped to the range 0-62.
Write the computed value into the upstream ratio field.

The upstream loss (from packet counting) and the sender's reported loss count are not perfectly synchronized. The observer's count reflects real-time loss for each interval, while the sender's count depends on acknowledgment processing and lags by approximately one round-trip time. To account for this, observers SHOULD compute the upstream ratio over multiple marker intervals. Aggregating over several intervals smooths out the timing difference and yields a ratio that converges to the true loss split. Any observer on the path MAY write the upstream ratio field, regardless of its current value. If no observer writes into the report, the receiver sees 63 and knows no observer participated.

Multiple Observers If multiple observers exist on the path, each may overwrite the previous value. The receiver therefore sees the perspective of the last observer on the path (closest to the receiver). This is a trade-off for simplicity. For downlink traffic, the last writer is typically the access network element closest to the receiving endpoint, which is often the most relevant viewpoint. For uplink traffic, the last writer is further from the user, which may be less useful. A single-observer deployment, which is the common case, is unaffected by this choice. Future extensions could define mechanisms for multiple observers to report independently.

Receiving Report Packets The receiver reads the upstream ratio field. A value of 63 indicates that no observer on the path wrote a measurement. Values 0 through 62 indicate an observer's estimate of the upstream loss fraction. Combined with its own end-to-end loss measurement, the receiver can estimate:

Upstream loss rate = end_to_end_loss * (upstream_ratio / 62)
Downstream loss rate = end_to_end_loss * (1 - upstream_ratio / 62)

The receiver can derive end-to-end loss either from its own acknowledgment processing or by counting packets between markers (applying the same technique as an observer). The latter provides an independent measurement that does not depend on ACK processing. The upstream ratio is a statistical estimate that converges over time. Receivers SHOULD average the ratio over multiple reports before drawing conclusions about loss localization. The receiver has no information about which network element wrote the ratio or where on the path it is positioned; see . A report packet MUST be discarded unless another QUIC packet in the same datagram is successfully processed.

Application Use Applications can use the loss localization information, for example, to:

Distinguish between access network issues and core/peering issues.
Inform path migration decisions when an endpoint has multiple available network accesses (e.g., Wi-Fi and cellular), by comparing loss characteristics across paths.
Provide diagnostic information to users or operators.

How applications use this information is out of scope for this document.

Applicability

Observer Location The POEM protocol does not carry any identifier or topology information about the observer that writes a report. The receiving endpoint knows only that some network element between the sender and itself provided a loss split — not where on the path that element is positioned. The interpretation of the upstream ratio depends on the observer's location. A ratio written by an element at the access network edge (e.g., a cellular UPF or broadband gateway) distinguishes access from non-access loss. A ratio written by an element in the network core provides a different, possibly less useful, split. A typical deployment involves a single observer in the access network. The protocol makes no guarantees about observer placement, however, and endpoints SHOULD NOT assume a particular observer location.

Unidirectional Signal POEM signals travel in the same direction as data. The receiver obtains loss localization information but the sender does not, unless the receiver communicates it back through other means. This is analogous to the model used by other on-path signaling protocols such as SCONE .

Per-Flow Scope POEM measurement applies to a single flow identified by the UDP 4-tuple. Separate flows receive independent measurements, even if they share the same endpoints or network path.

Negotiating POEM A QUIC endpoint indicates that it is able to receive POEM packets by including the poem_supported transport parameter (0xTBD) in the QUIC handshake. Each endpoint independently indicates willingness to receive POEM packets. An endpoint that does not include the poem_supported transport parameter can send POEM packets if its peer includes the transport parameter. The poem_supported transport parameter MUST be empty. Receiving a non-zero length value MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT remember whether the poem_supported transport parameter was present on the previous connection when using 0-RTT. That is, POEM packets cannot be sent on a connection until the transport parameter is received.

Security Considerations

On-Path Modification POEM relies on on-path network elements modifying report packets. The ability to modify packets demonstrates that the element is positioned to observe and potentially drop traffic, the same trust model as SCONE .

Fake POEM Packets An attacker that can inject packets could construct fake POEM packets. Endpoints mitigate this by only accepting POEM information from datagrams containing a successfully processed QUIC packet. Off-path attackers cannot construct valid QUIC packets.

Misleading Reports An on-path observer could write misleading upstream ratio values. However, such an observer already has the ability to drop or delay packets. Endpoints SHOULD treat POEM reports as advisory and cross-reference with their own measurements.

Interaction with Loss Detection The loss count reveals information about the sender's loss detection state. This is similar to information derivable from timing analysis and congestion controller behavior, and does not represent significant new exposure beyond what is available to on-path observers.

Falsified Loss Signals An endpoint can falsify POEM signals in two ways:

Inflated marker frequency:: Sending markers more frequently than the specified interval of 64 packets causes observers to perceive upstream loss that does not exist. For example, sending markers every 32 packets makes it appear that 50% of packets are lost upstream.
Inflated loss count:: Reporting a higher loss count than actually observed causes the observer to conclude that downstream loss exists. Since downstream loss typically falls within the operator's domain, this may trigger investigation or remediation of non-existent faults.
Deflated loss count:: Reporting a lower loss count than actually observed (including always reporting 0) causes the observer to attribute all observed loss to the upstream segment, concealing downstream loss.

In both cases, the observer has no reliable way to verify the endpoint's claims. Network operators MUST NOT use POEM signals as the sole input to automated network policy, assurance, or engineering decisions. POEM measurements from untrusted endpoints should be cross-referenced with other data sources before acting on them.

Privacy Considerations

Flow Identification POEM packets do not introduce new flow identifiers beyond what is already visible in the UDP 4-tuple and QUIC connection IDs.

Measurement Exposure The loss count in marker packets reveals the sender's view of end-to-end loss. This information is visible to all on-path elements between the sender and receiver. The upstream ratio in report packets (once written by an observer) reveals loss localization to downstream observers and the receiver.

IANA Considerations This document requests the following registrations.

POEM Version Numbers This document registers the following entries in the "QUIC Versions" registry:

Value:: 0xTBD1
Status:: permanent
Specification:: This document
Change Controller:: IETF (iesg@ietf.org)
Contact:: QUIC Working Group (quic@ietf.org)
Notes:: POEM Marker Packet

Value:: 0xTBD2
Status:: permanent
Specification:: This document
Change Controller:: IETF (iesg@ietf.org)
Contact:: QUIC Working Group (quic@ietf.org)
Notes:: POEM Report Packet

poem_supported Transport Parameter This document registers the following entry in the "QUIC Transport Parameters" registry:

Value:: 0xTBD
Parameter Name:: poem_supported
Status:: Permanent
Specification:: This document
Change Controller:: IETF (iesg@ietf.org)
Contact:: QUIC Working Group (quic@ietf.org)
Notes:: (none)

References Normative References QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Version-Independent Properties of QUIC This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Greasing the QUIC Bit This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. Informative References Standard Communication with Network Elements (SCONE) Protocol Mozilla Private Octopus Inc. Fastly Meta Ericsson This document describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals. Explicit Host-to-Network Flow Measurements Techniques This document describes protocol-independent methods called Explicit Host-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied. Alternate-Marking Method This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. Application of Explicit Measurement Techniques for QUIC Troubleshooting Orange Labs Akamai Technologies Huawei Technologies Ericsson CUJO AI This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements).

Design Considerations

Marker Interval Selection The fixed interval of 64 packets is a trade-off. Shorter intervals provide more frequent measurements at the cost of higher overhead. Longer intervals reduce overhead but yield fewer samples and slower detection of changes in loss patterns. Future versions of this protocol may allow endpoints to select from a set of predefined intervals, with observers inferring the interval from packet counting and the alternating counter bit.

Comparison with Per-Packet Approaches Per-packet signals such as those in provide finer-grained measurements from every packet. POEM trades granularity for lower overhead: only ~1.5% of packets carry POEM headers, and observers use simple packet counting rather than per-packet bit tracking. POEM is suited to deployments where statistical loss estimates over multiple intervals are sufficient.

Acknowledgments This work is inspired by the explicit measurement techniques defined in and the architectural approach of the SCONE protocol .