A Protocol for Periodic On-path Explicit Measurement
draft-ihlar-poem-quic-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Marcus Ihlar , Mirja Kühlewind | ||
| Last updated | 2026-07-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ihlar-poem-quic-01
SCONE M. Ihlar
Internet-Draft M. Kühlewind
Intended status: Informational Ericsson
Expires: 21 January 2027 20 July 2026
A Protocol for Periodic On-path Explicit Measurement
draft-ihlar-poem-quic-01
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.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ihlar-poem-quic/.
Discussion of this document takes place on the SCONE Working Group
mailing list (mailto:scone@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/scone/. Subscribe at
https://www.ietf.org/mailman/listinfo/scone/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Ihlar & Kühlewind Expires 21 January 2027 [Page 1]
Internet-Draft POEM July 2026
This Internet-Draft will expire on 21 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Marker Packets . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Marker Packet Format . . . . . . . . . . . . . . . . . . 5
4.2. Marker Interval . . . . . . . . . . . . . . . . . . . . . 7
4.3. Sender Loss Count Semantics . . . . . . . . . . . . . . . 7
4.4. Sending Marker Packets . . . . . . . . . . . . . . . . . 7
4.5. Observing Marker Packets . . . . . . . . . . . . . . . . 8
4.6. Receiving Marker Packets . . . . . . . . . . . . . . . . 9
4.7. Connection Migration . . . . . . . . . . . . . . . . . . 9
5. Report Packets . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Report Packet Format . . . . . . . . . . . . . . . . . . 9
5.2. Upstream Ratio Semantics . . . . . . . . . . . . . . . . 10
5.3. Sending Report Packets . . . . . . . . . . . . . . . . . 11
5.4. Observing Report Packets . . . . . . . . . . . . . . . . 11
5.4.1. Multiple Observers . . . . . . . . . . . . . . . . . 12
5.5. Receiving Report Packets . . . . . . . . . . . . . . . . 12
5.6. Application Use . . . . . . . . . . . . . . . . . . . . . 13
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Observer Location . . . . . . . . . . . . . . . . . . . . 13
6.2. Unidirectional Signal . . . . . . . . . . . . . . . . . . 13
6.3. Per-Flow Scope . . . . . . . . . . . . . . . . . . . . . 14
7. Negotiating POEM . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. On-Path Modification . . . . . . . . . . . . . . . . . . 14
8.2. Fake POEM Packets . . . . . . . . . . . . . . . . . . . . 14
8.3. Misleading Reports . . . . . . . . . . . . . . . . . . . 14
8.4. Interaction with Loss Detection . . . . . . . . . . . . . 15
8.5. Falsified Loss Signals . . . . . . . . . . . . . . . . . 15
Ihlar & Kühlewind Expires 21 January 2027 [Page 2]
Internet-Draft POEM July 2026
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Flow Identification . . . . . . . . . . . . . . . . . . . 15
9.2. Measurement Exposure . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. POEM Version Numbers . . . . . . . . . . . . . . . . . . 16
10.2. poem_supported Transport Parameter . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Design Considerations . . . . . . . . . . . . . . . 18
A.1. Marker Interval Selection . . . . . . . . . . . . . . . . 18
A.2. Comparison with Per-Packet Approaches . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 3]
Internet-Draft POEM July 2026
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.
2. 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 [RFC2119] [RFC8174] 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.
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
Ihlar & Kühlewind Expires 21 January 2027 [Page 4]
Internet-Draft POEM July 2026
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 5]
Internet-Draft POEM July 2026
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 6]
Internet-Draft POEM July 2026
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:
Ihlar & Kühlewind Expires 21 January 2027 [Page 7]
Internet-Draft POEM July 2026
1. Maintain a packet counter, initialized to 0 after each marker.
2. 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.
3. 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.
4. 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:
1. Records the current packet count for the flow (identified by the
UDP 4-tuple) since and including the previous marker.
2. 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).
Ihlar & Kühlewind Expires 21 January 2027 [Page 8]
Internet-Draft POEM July 2026
3. Reads the loss count field, which indicates the sender's observed
end-to-end loss for the preceding interval.
4. 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).
5. 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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 9]
Internet-Draft POEM July 2026
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 10]
Internet-Draft POEM July 2026
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:
1. Compute the upstream loss rate from recent marker intervals.
2. Compute the total loss rate from the sender's reported loss
counts over the same intervals.
3. If total loss is non-zero, compute: upstream_ratio =
(upstream_loss / total_loss) * 62, clamped to the range 0-62.
4. 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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 11]
Internet-Draft POEM July 2026
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 12]
Internet-Draft POEM July 2026
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.
6. Applicability
6.1. 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.
6.2. 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 [SCONE].
Ihlar & Kühlewind Expires 21 January 2027 [Page 13]
Internet-Draft POEM July 2026
6.3. 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.
7. 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.
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.
Ihlar & Kühlewind Expires 21 January 2027 [Page 14]
Internet-Draft POEM July 2026
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.
9. Privacy Considerations
9.1. Flow Identification
POEM packets do not introduce new flow identifiers beyond what is
already visible in the UDP 4-tuple and QUIC connection IDs.
Ihlar & Kühlewind Expires 21 January 2027 [Page 15]
Internet-Draft POEM July 2026
9.2. 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.
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
Ihlar & Kühlewind Expires 21 January 2027 [Page 16]
Internet-Draft POEM July 2026
[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,
Ihlar & Kühlewind Expires 21 January 2027 [Page 17]
Internet-Draft POEM July 2026
draft-ietf-scone-protocol-05, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scone-
protocol-05>.
Appendix A. Design Considerations
A.1. 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.
A.2. Comparison with Per-Packet Approaches
Per-packet signals such as those in [EFMP] 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 [EXPLICIT-MEASUREMENTS] and the architectural approach of the
SCONE protocol [SCONE].
Authors' Addresses
Marcus Ihlar
Ericsson
Email: marcus.ihlar@ericsson.com
Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
Ihlar & Kühlewind Expires 21 January 2027 [Page 18]