A Protocol for Periodic On-path Explicit Measurement

Internet-Draft	POEM	July 2026
Ihlar & Kühlewind	Expires 21 January 2027	[Page]

Abstract

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.¶

1. 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 [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 [EXPLICIT-MEASUREMENTS] have been proposed to address this, where endpoints cooperate by exposing measurement signals in the clear portion of packets.¶

The Explicit Flow Measurement Protocol [EFMP] defines a per-packet signaling approach based on the Alternate-Marking method [AltMark], 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 [SCONE], 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.¶

3. Protocol Overview

POEM operates alongside QUIC connections. Endpoints negotiate POEM support using a QUIC transport parameter (Section 7). 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.¶

Figure 1 shows the basic operation of POEM.¶

+--------+         +----------+           +----------+
|  QUIC  |         |          |           |   QUIC   |
| Sender |         | Observer |           | Receiver |
+---+----+         +----+-----+           +----+-----+
    |                   |                      |
    |--- MARKER(c=0, -->|--- MARKER(c=0, ----->|
    |    L=0) + QUIC    |    L=0) + QUIC       |
    |                   |                      |
    |--- data pkt 1 --->|--- data pkt 1 ------>|
    |--- data pkt 2 --->|    (lost)            |
    |       ...         |       ...            |
    |--- data pkt 63 -->|--- data pkt 62 ----->|
    |                   |                      |
    |--- MARKER(c=1, -->|--- MARKER(c=1, ----->|
    |    L=0) + QUIC    |    L=0) + QUIC       |
    |                   |                      |
    |  Observer counts 63 pkts between markers |
    |  and detects 1 upstream loss             |
    |                   |                      |
    |--- REPORT + QUIC->|--- (writes ratio) -->|
    |                   |                      |

Figure 1: POEM Protocol Operation

Signals flow in the same direction as the data packets. The marker and report packets travel from sender to receiver, and any measurement written by the observer is read by the receiver. If the receiver needs to communicate measurement information to the sender, it does so via mechanisms outside the scope of this document.¶

4. Marker Packets

4.1. Marker Packet Format

A marker packet is a QUIC long header packet that follows the QUIC invariants; see Section 5.1 of [INVARIANTS].¶

Figure 2 shows the format of the marker packet.¶

Marker Packet {
  Header Form (1) = 1,
  Reserved (1),
  Counter (1),
  Loss Count (5),
  Version (32) = 0xTBD1,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
}

Figure 2: 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 [QUIC-BIT].¶
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 Section 12.2 of [QUIC].¶
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.¶

4.2. 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.¶

4.3. Sender Loss Count Semantics

The sender maintains an Unreported Loss counter, as defined in [EXPLICIT-MEASUREMENTS], that persists across marker intervals. Unlike [EXPLICIT-MEASUREMENTS], 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."¶

4.4. Sending Marker Packets

POEM packets can only be sent once both endpoints have exchanged the poem_supported transport parameter (Section 7). 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.¶

4.5. 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.¶

4.6. 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.¶

4.7. 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.¶

5. Report Packets

5.1. 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.¶

Figure 3 shows the format of the report packet.¶

Report Packet {
  Header Form (1) = 1,
  Reserved (1),
  Upstream Ratio (6),
  Version (32) = 0xTBD2,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
}

Figure 3: 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 [QUIC-BIT].¶
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 (Section 4).¶

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

5.2. 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.¶

5.3. 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.¶

5.4. 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.¶

5.4.1. 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.¶

5.5. 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 Section 6.¶

A report packet MUST be discarded unless another QUIC packet in the same datagram is successfully processed.¶

5.6. 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.¶

8. Security Considerations

8.1. 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 [SCONE].¶

8.2. 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.¶

8.3. 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.¶

8.4. 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.¶

8.5. 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.¶

10. IANA Considerations

This document requests the following registrations.¶

10.1. 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¶

10.2. 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)¶

11. References

11.1. Normative References

[INVARIANTS]: Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/rfc/rfc8999>.
[QUIC]: Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.
[QUIC-BIT]: Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, August 2022, <https://www.rfc-editor.org/rfc/rfc9287>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[AltMark]: Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, <https://www.rfc-editor.org/rfc/rfc9341>.
[EFMP]: Ferrieux, A., Lubashev, I., Fioccola, G., Ihlar, L. M., Kunze, I., Bulgarella, F., and M. Cociglio, "Application of Explicit Measurement Techniques for QUIC Troubleshooting", Work in Progress, Internet-Draft, draft-mdt-quic-explicit-measurements-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-mdt-quic-explicit-measurements-05>.
[EXPLICIT-MEASUREMENTS]: Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I., Bulgarella, F., Nilo, M., Hamchaoui, I., and R. Sisto, "Explicit Host-to-Network Flow Measurements Techniques", RFC 9506, DOI 10.17487/RFC9506, October 2023, <https://www.rfc-editor.org/rfc/rfc9506>.
[SCONE]: Thomson, M., Huitema, C., Oku, K., Joras, M., and L. M. Ihlar, "Standard Communication with Network Elements (SCONE) Protocol", Work in Progress, Internet-Draft, draft-ietf-scone-protocol-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scone-protocol-05>.