SCONE M. Ihlar Internet-Draft M. Kühlewind Intended status: Informational Ericsson Expires: 6 May 2027 2 November 2026 Periodic On-path Explicit Measurement of Delay draft-ihlar-poem-delay-quic-00 Abstract This document defines POEM Delay, a delay measurement companion to the Periodic On-path Explicit Measurement (POEM) protocol for QUIC. A delay sample packet, coalesced with ordinary QUIC packets, bounces between the endpoints. On-path observers timestamp it in each direction to measure the round-trip time and its components on either side of the observer. Each sample carries a coarse indication of how long the sending endpoint held it, so observers can largely exclude endpoint delay. A report packet lets observers tell endpoints how network delay is split between the two sides of the observer. 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-delay-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 6 May 2027 [Page 1] Internet-Draft POEM Delay November 2026 This Internet-Draft will expire on 6 May 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Delay Sample Packets . . . . . . . . . . . . . . . . . . . . 5 4.1. Delay Sample Packet Format . . . . . . . . . . . . . . . 5 4.2. Response Delay . . . . . . . . . . . . . . . . . . . . . 7 4.3. Generation . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Reflection . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Reflection Opportunities . . . . . . . . . . . . . . . . 9 4.6. Receiving Delay Samples . . . . . . . . . . . . . . . . . 9 4.7. Connection Migration . . . . . . . . . . . . . . . . . . 10 5. Observing Delay Samples . . . . . . . . . . . . . . . . . . . 10 5.1. Bidirectional Observers . . . . . . . . . . . . . . . . . 10 5.2. Unidirectional Observers . . . . . . . . . . . . . . . . 10 5.3. Validity of Measurements . . . . . . . . . . . . . . . . 11 5.4. Observer State . . . . . . . . . . . . . . . . . . . . . 11 6. Delay Report Packets . . . . . . . . . . . . . . . . . . . . 11 6.1. Delay Report Packet Format . . . . . . . . . . . . . . . 11 6.2. Sending Delay Report Packets . . . . . . . . . . . . . . 12 6.3. Observing Delay Report Packets . . . . . . . . . . . . . 12 6.4. Receiving Delay Report Packets . . . . . . . . . . . . . 12 6.5. Application Use . . . . . . . . . . . . . . . . . . . . . 13 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Observer Location . . . . . . . . . . . . . . . . . . . . 13 7.2. Measurement Rate and Accuracy . . . . . . . . . . . . . . 13 7.3. Bidirectional Requirement . . . . . . . . . . . . . . . . 13 7.4. Per-Flow Scope . . . . . . . . . . . . . . . . . . . . . 13 7.5. Relationship to the Spin Bit . . . . . . . . . . . . . . 14 8. Negotiating POEM Delay . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Ihlar & Kühlewind Expires 6 May 2027 [Page 2] Internet-Draft POEM Delay November 2026 9.1. On-Path Modification . . . . . . . . . . . . . . . . . . 14 9.2. Fake Packets . . . . . . . . . . . . . . . . . . . . . . 14 9.3. Misleading Reports . . . . . . . . . . . . . . . . . . . 15 9.4. Falsified Delay Signals . . . . . . . . . . . . . . . . . 15 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 10.1. Flow Identification . . . . . . . . . . . . . . . . . . 15 10.2. Endpoint Roles . . . . . . . . . . . . . . . . . . . . . 15 10.3. Delay Exposure . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11.1. POEM Delay Version Numbers . . . . . . . . . . . . . . . 16 11.2. poem_delay_supported Transport Parameter . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction QUIC [QUIC] encrypts the transport header fields that on-path observers use to measure delay for TCP. This document defines POEM Delay, an explicit delay signal for QUIC. Like the existing signals, it trades accuracy against how often a measurement succeeds: * The spin bit (Section 17.4 of [QUIC]) yields a measurement every round trip for any traffic, but includes endpoint idle time, which can be long when the application limits sending. Reordering and loss cause further errors. * The Delay bit [EXPLICIT-MEASUREMENTS] uses a single marked packet, the delay sample, that bounces between client and server. An endpoint that cannot reflect the sample within 1 ms drops it, so measurements are accurate, but many samples are dropped when the application limits sending or when acknowledgments are delayed by more than 1 ms. * POEM Delay keeps the accuracy of the Delay bit while more measurements succeed. Endpoints can hold the sample up to 30 ms and report the coarse response delay, which observers subtract. POEM Delay carries the delay sample in a QUIC long header packet coalesced with ordinary QUIC packets, following SCONE [SCONE] and the loss measurement protocol of [POEM], called POEM Loss here. As in those protocols, all information is in the first octet. Compared with the Delay bit, it adds: * a Sample ID, which keeps observers from pairing unrelated samples, such as a lost sample and its replacement, and Ihlar & Kühlewind Expires 6 May 2027 [Page 3] Internet-Draft POEM Delay November 2026 * a coarse response delay, which observers subtract to measure network delay rather than network plus endpoint delay. A delay report packet, analogous to the POEM Loss report, lets an observer tell an endpoint how network delay is split between the two sides of the observer. POEM Loss and POEM Delay are independent and can be used together. 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. This document uses the following terms: Delay sample: The packet that bounces between the endpoints (Section 4). Sample chain: A delay sample generated by the client and its reflections, all carrying the same Sample ID. Generation: Sending a delay sample that starts a new chain. Only the client generates. Reflection: Sending a delay sample in response to receiving one. Response delay: The time an endpoint holds a delay sample before reflecting it. Observer: An on-path network element that timestamps delay samples or writes into delay report packets. Component: The round-trip delay between the observer and one endpoint. Network RTT: The round-trip time excluding the response delay of both endpoints. Ihlar & Kühlewind Expires 6 May 2027 [Page 4] Internet-Draft POEM Delay November 2026 3. Overview After negotiating support (Section 8), the client generates a delay sample. Each endpoint reflects a received sample in the next datagram it sends, so the sample crosses the path once in each direction per round trip. Each sample carries a 2-bit Sample ID and a 4-bit Response Delay, which indicates in coarse steps how long the sender held it. An observer timestamps each sample as it passes (Figure 1). +--------+ +----------+ +--------+ | Client | | Observer | | Server | +---+----+ +----+-----+ +----+---+ | | | |---- DS(id,..) ----->| t0 | | |--------------------->| | | | D1 | |<----- DS(id,D1) -----| |<--------------------| t1 | D2 | | | |---- DS(id,D2) ----->| t2 | | |--------------------->| | | | Server component (network) = t1 - t0 - D1 Client component (network) = t2 - t1 - D2 Network RTT = t2 - t0 - D1 - D2 Figure 1: Delay Sample Operation An observer that sees both directions measures both components and the network RTT. An observer that sees one direction measures the RTT, but can only subtract the response delay of one endpoint (Section 5.2). Endpoints can also send delay reports (Section 6), into which an observer writes the fraction of the network RTT on the report sender's side. 4. Delay Sample Packets 4.1. Delay Sample Packet Format A delay sample packet is a QUIC long header packet that follows the QUIC invariants; see Section 5.1 of [INVARIANTS]. Ihlar & Kühlewind Expires 6 May 2027 [Page 5] Internet-Draft POEM Delay November 2026 Delay Sample Packet { Header Form (1) = 1, Reserved (1), Sample ID (2), Response Delay (4), Version (32) = 0xTBD3, Destination Connection ID Length (8), Destination Connection ID (0..2040), Source Connection ID Length (8), Source Connection ID (0..2040), } Figure 2: Delay Sample Packet Format 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]. Sample ID: A 2-bit value (0x30) identifying the chain. Response Delay: A 4-bit code (0x0f) for the response delay of the sender (Section 4.2). Version: Set to 0xTBD3, identifying a POEM Delay sample packet. Destination Connection ID Length and Destination Connection ID: Set to the same value as other packets in the datagram; see Section 12.2 of [QUIC]. Source Connection ID Length and Source Connection ID: Set to match the Source Connection ID of the packet that follows in the datagram, or empty if that packet has a short header. Delay sample packets MUST be coalesced with other QUIC packets and MUST be the first packet in the UDP datagram. As in SCONE [SCONE] and POEM Loss [POEM], all signals are in the first octet. This leaves the space after the connection IDs to the coalesced QUIC packet and lets observers read the signals at a fixed offset, without parsing the variable-length connection IDs. SCONE packets and POEM Loss packets also need to be first, so a datagram carries at most one of these, a delay sample, or a delay report. A reflection that cannot go in the next datagram for this reason is sent in a later one, and the wait counts as response delay. Endpoints SHOULD NOT add an optional packet of this kind, such as a delay report, to a datagram while a reflection is pending. Ihlar & Kühlewind Expires 6 May 2027 [Page 6] Internet-Draft POEM Delay November 2026 4.2. Response Delay The response delay runs from receiving the datagram carrying a delay sample to sending the datagram carrying its reflection. Typically, an endpoint records the receive time when it extracts the sample and computes the response delay when it builds the reflection. A receive time recorded before the coalesced QUIC packet is processed is discarded if that packet is not successfully processed. The Response Delay field encodes the response delay in 2 ms steps: +======+====================+===================+ | Code | Response delay | Observer estimate | +======+====================+===================+ | 0 | 0 ms to < 2 ms | 1 ms | +------+--------------------+-------------------+ | 1 | 2 ms to < 4 ms | 3 ms | +------+--------------------+-------------------+ | n | 2n ms to < 2n+2 ms | 2n+1 ms | +------+--------------------+-------------------+ | 14 | 28 ms to < 30 ms | 29 ms | +------+--------------------+-------------------+ | 15 | Not reported | (none) | +------+--------------------+-------------------+ Table 1: Response Delay Codes The 2 ms granularity balances measurement accuracy against exposure of endpoint-internal timing, such as cryptographic processing time (Section 10.3). An endpoint MUST NOT reflect a sample if the response delay would reach MAX_RESPONSE_DELAY, which is 30 ms. The sample is dropped and the chain ends. This value covers the default max_ack_delay of 25 ms in QUIC versions 1 and 2 (Section 18.2 of [QUIC]), and a fixed limit lets the client choose T_Max (Section 4.3) without knowing the server's acknowledgment behavior. Generated samples carry code 15. An endpoint MAY also send code 15 in a reflection, for example if it does not want to expose its response delay. 4.3. Generation Only the client generates delay samples. When and whether to generate is up to the client; the server reflects any chain it receives. A client that wants continuous measurement starts a new chain: Ihlar & Kühlewind Expires 6 May 2027 [Page 7] Internet-Draft POEM Delay November 2026 * in one of its first datagrams after receiving the server's transport parameter, * on a new path, once it is permitted to send on it (Section 4.7), * when T_Max has elapsed since it last sent a sample of the current chain without accepting a reflection, and * when a chain ends because of the response delay limit or the chain length limit (below). A generated sample carries the Sample ID of the previous chain on the path plus one, modulo 4 (any value for the first chain), and Response Delay 15. T_Max needs to exceed the RTT plus the server's response delay, so that the client does not replace chains still in flight. A suitable value is twice the smoothed RTT plus MAX_RESPONSE_DELAY, or 1 second until an RTT estimate is available, such as the smoothed RTT of QUIC versions 1 and 2 (Section 5.3 of [RECOVERY]). A client MUST NOT reflect a sample after accepting MAX_CHAIN_REFLECTIONS reflections of the current chain, where MAX_CHAIN_REFLECTIONS is 8. This ends the chain and bounds the effect of extra samples that the acceptance rules cannot detect (Section 4.4). If the client starts a new chain in its place, observers lose about one measurement per 8 round trips, since a generated sample is never the later sample of a pair. A client can stop generating at any time, for example when the connection is idle. If it also stops reflecting, the chain ends. 4.4. Reflection Each endpoint keeps, per path, the Sample ID of the current chain and whether it is awaiting a sample, that is, whether it has sent a sample of the chain and not yet accepted one in return. A server accepts a delay sample when: * its Sample ID differs from the current chain, which starts a new chain; * its Sample ID matches the current chain and the server is awaiting a sample; or * the server has no chain on this path, for example after a NAT rebinding, which makes the sample's chain current. Ihlar & Kühlewind Expires 6 May 2027 [Page 8] Internet-Draft POEM Delay November 2026 A client accepts a delay sample when its Sample ID matches the current chain and the client is awaiting a sample. Other samples are discarded without changing the chain state. An endpoint can also decline an acceptable sample, for example because of load, which ends the chain. An endpoint reflects an accepted sample in the first datagram it sends on the same path that can carry it, copying the Sample ID and setting the Response Delay. It can hold the reflection longer to mask the RTT (Section 10.3), within MAX_RESPONSE_DELAY. If it accepts a sample of a new chain while holding one, it reflects only the new one. Endpoints record when they send each sample. With QUIC duplicate detection (Section 4.6), these rules normally keep one sample in flight per chain and let the client end stale chains by not reflecting them. A late sample of an old chain costs at most one reflection, or the current chain if the server is holding a sample. The rules cannot detect a second sample with the current Sample ID, for example one injected on path or a stale sample after the Sample ID wraps; MAX_CHAIN_REFLECTIONS bounds how long such a sample circulates. 4.5. Reflection Opportunities An endpoint MUST NOT send a datagram, or send it earlier, solely to carry a delay sample. Delay samples therefore never generate traffic or affect idle timeouts. If no datagram is sent within MAX_RESPONSE_DELAY, the chain ends. When they have a choice, endpoints SHOULD carry delay samples in datagrams that the peer will respond to promptly, giving the peer an opportunity to reflect. In QUIC versions 1 and 2, these are datagrams containing ack-eliciting packets, which the peer acknowledges within its max_ack_delay (Section 13.2.1 of [QUIC]). 4.6. Receiving Delay Samples A delay sample MUST be discarded unless another QUIC packet in the same datagram is successfully processed. QUIC packets discarded as duplicates are not successfully processed, so endpoints ignore duplicated samples. This relies on the QUIC version discarding duplicates, as versions 1 and 2 do (Section 12.3 of [QUIC]); delay samples MUST NOT be used with versions that do not. Ihlar & Kühlewind Expires 6 May 2027 [Page 9] Internet-Draft POEM Delay November 2026 4.7. Connection Migration Delay sample state is per path. After migrating, the client starts a new chain once it is permitted to send on the new path. Endpoints discard chain state for paths no longer in use. Endpoints SHOULD NOT send delay samples on a path while the QUIC version restricts sending on it, such as before path validation in QUIC versions 1 and 2. Delay samples count toward any anti- amplification limit, such as that in Section 8.1 of [QUIC]. 5. Observing Delay Samples An observer identifies delay sample packets by the long header bit (0x80) and the version 0xTBD3, and determines their direction from the UDP 4-tuple. Observers do not modify delay samples. Below, D is the observer estimate for the Response Delay of the later sample of a pair (Table 1). Each subtraction of D has an error of up to 1 ms. 5.1. Bidirectional Observers An observer that sees both directions measures a component from two consecutive samples of the same chain in opposite directions, seen at t1 and t2: component = t2 - t1 - D This is the network component toward the endpoint the earlier sample was sent to. Two consecutive components add up to the network RTT. 5.2. Unidirectional Observers Any observer can measure the RTT from two consecutive samples of the same chain in the same direction, seen at t1 and t2: rtt = t2 - t1 - D This subtracts the response delay of the endpoint sending the observed samples, but not that of the other endpoint, which is carried in the direction the observer does not see. The result is the network RTT plus up to MAX_RESPONSE_DELAY. Ihlar & Kühlewind Expires 6 May 2027 [Page 10] Internet-Draft POEM Delay November 2026 5.3. Validity of Measurements Observers MUST only pair samples with the same Sample ID. A sample with a new Sample ID starts a chain and is never the later sample of a pair. If the later sample has Response Delay 15, D is 0 and the result includes that endpoint's response delay, which is less than MAX_RESPONSE_DELAY. Such results are comparable to Delay bit measurements. Samples of a chain alternate in direction. If a bidirectional observer sees two samples in the same direction with none in between, one is a duplicate or a sample was missed. It MUST NOT use either for a component, and resumes with the next sample in the opposite direction. Otherwise, observers cannot detect duplicates or missed samples, and chains they do not see can bring the Sample ID back to the same value. Observers therefore discard implausible results, such as negative values or intervals much shorter or longer than recent measurements. 5.4. Observer State Per flow, an observer keeps the Sample ID of the current chain and, per direction, the time and Response Delay of the most recent sample, marked invalid after a repeat in the same direction. 6. Delay Report Packets 6.1. Delay Report Packet Format A delay report packet is a QUIC long header packet into which an observer writes delay localization information for the receiver. Delay Report Packet { Header Form (1) = 1, Reserved (1), Upstream Delay Ratio (6), Version (32) = 0xTBD4, Destination Connection ID Length (8), Destination Connection ID (0..2040), Source Connection ID Length (8), Source Connection ID (0..2040), } Figure 3: Delay Report Packet Format Ihlar & Kühlewind Expires 6 May 2027 [Page 11] Internet-Draft POEM Delay November 2026 Header Form, Reserved, and Connection ID fields: As for delay sample packets (Section 4). Upstream Delay Ratio: A 6-bit value (0x3f). Values 0 to 62 represent the fraction value/62 of the network RTT between the report sender and the observer. The value 63 means no observer wrote the field; endpoints MUST send 63. Version: Set to 0xTBD4, identifying a POEM Delay report packet. Delay report packets follow the coalescing rules for delay sample packets (Section 4). 6.2. Sending Delay Report Packets Either endpoint MAY send delay reports. Endpoints SHOULD NOT send more than one per network round trip; one every 4 to 8 round trips is RECOMMENDED. 6.3. Observing Delay Report Packets An observer identifies delay report packets by the long header bit (0x80) and the version 0xTBD4. The upstream component is the one toward the report sender. An observer that has not measured both components MUST NOT write the field. Otherwise, it MAY write: ratio = upstream / (upstream + downstream) * 62 rounded and clamped to 0-62, using network components from consecutive pairs of the same chain. Observers SHOULD average over multiple round trips to reduce the effect of transient queuing and response delay quantization; the method is up to the observer. Any observer MAY overwrite the field. As in POEM Loss [POEM], the receiver sees the value from the last observer on the path. 6.4. Receiving Delay Report Packets A delay report packet MUST be discarded unless another QUIC packet in the same datagram is successfully processed. A value of 63 means no observer wrote the field. Otherwise, the receiver can combine the ratio with its own network RTT estimate over a similar period: * Component toward the report sender = network_rtt * ratio / 62 Ihlar & Kühlewind Expires 6 May 2027 [Page 12] Internet-Draft POEM Delay November 2026 * Component toward the receiver = network_rtt * (1 - ratio / 62) RTT estimates from QUIC loss recovery (Section 5 of [RECOVERY]) include endpoint delay and would bias the result. Receivers SHOULD average over multiple reports. 6.5. Application Use Applications can use delay localization, for example, to distinguish access network delay from delay elsewhere on the path, to inform path selection when multiple network accesses are available, or for diagnostics. How applications use this information is out of scope. 7. Applicability 7.1. Observer Location As in POEM Loss [POEM], reports do not identify the observer or its location. Endpoints SHOULD NOT assume a particular observer location. 7.2. Measurement Rate and Accuracy A bidirectional observer gets at most one component measurement per one-way trip, and any observer at most one RTT measurement per round trip. Sample loss and long response delays reduce this rate, and delay variation within an RTT cannot be measured. The coarse Response Delay adds an error of up to 1 ms per subtracted response delay, which averaging reduces when response delays vary. 7.3. Bidirectional Requirement Unlike POEM Loss, POEM Delay requires both endpoints to reflect samples. Components, network RTT, and reports require an observer that sees both directions. With asymmetric routing, observers measure an RTT that includes one endpoint's response delay. 7.4. Per-Flow Scope Measurements apply to a single flow identified by the UDP 4-tuple. Ihlar & Kühlewind Expires 6 May 2027 [Page 13] Internet-Draft POEM Delay November 2026 7.5. Relationship to the Spin Bit Delay samples and the spin bit are independent. Observers can prefer delay sample measurements, which largely exclude endpoint delay and tolerate reordering, and fall back to the spin bit when none are recent; see Section 2.2.6 of [EXPLICIT-MEASUREMENTS]. 8. Negotiating POEM Delay An endpoint indicates that it can receive and reflect delay samples by including the poem_delay_supported transport parameter (0xTBD). Endpoints MUST NOT send delay sample packets unless both endpoints included the transport parameter. An endpoint MAY send delay report packets if its peer included it. The transport parameter MUST be empty. A non-zero length MUST be treated as a connection error of type TRANSPORT_PARAMETER_ERROR. This transport parameter is valid for QUIC versions 1 [QUIC] and 2 [QUICv2] and any other version that recognizes the versions and transport parameters registries established in Sections 22.2 and 22.3 of [QUIC]. Endpoints MUST NOT remember the transport parameter for 0-RTT, so delay sample and delay report packets cannot be sent until it is received. 9. Security Considerations 9.1. On-Path Modification Delay reports rely on on-path elements modifying packets, the same trust model as SCONE [SCONE] and POEM Loss [POEM]: an element that can modify packets can also drop or delay them. Delay sample fields are not integrity protected. An on-path element can change the Response Delay to mislead other observers, change the Sample ID to end the chain or revive a stale one, or add a second sample with the current Sample ID. The effect is limited to incorrect or lost measurements until the chain ends, after at most MAX_CHAIN_REFLECTIONS client reflections (Section 4.3). 9.2. Fake Packets Endpoints only accept delay samples and reports from datagrams with a successfully processed QUIC packet, which off-path attackers cannot construct. Ihlar & Kühlewind Expires 6 May 2027 [Page 14] Internet-Draft POEM Delay November 2026 9.3. Misleading Reports An observer can write misleading ratios. Endpoints SHOULD treat reports as advisory and compare them with their own measurements. 9.4. Falsified Delay Signals Endpoints can falsify delay samples: Inflated response delay: Observers underestimate network delay, possibly producing negative values, which are discarded. Deflated response delay: Endpoint delay is attributed to the network between the observer and that endpoint. Extra samples: Generating samples at a high rate or reflecting samples that should not be accepted puts multiple samples in flight, producing meaningless measurements. Observers cannot verify endpoint claims. Network operators MUST NOT use POEM Delay signals as the sole input to automated network policy, assurance, or engineering decisions, and should compare measurements from untrusted endpoints with other data. 10. Privacy Considerations 10.1. Flow Identification Delay sample and report packets add no flow identifiers beyond the UDP 4-tuple and connection IDs. Chain state is not carried across paths, and a 2-bit Sample ID cannot meaningfully link paths. 10.2. Endpoint Roles An observer that sees a new Sample ID appear can identify the client, which is the only generator. Observers that see the handshake already know this, and no measurement here uses it. 10.3. Delay Exposure Delay samples expose the RTT and, to bidirectional observers, the RTT to each endpoint. The spin bit already exposes the RTT; [EXPLICIT-MEASUREMENTS] discusses the privacy implications. A precise response delay would directly reveal endpoint-internal timing, such as cryptographic processing time, scheduling, or load. The 2 ms steps avoid this, but do not prevent inference: observers see the total interval between samples, so where network delay is Ihlar & Kühlewind Expires 6 May 2027 [Page 15] Internet-Draft POEM Delay November 2026 stable they can infer response delay variation from timing alone, as with the spin bit and Delay bit. Over many samples, jitter around step boundaries can reveal finer detail, and the code itself distinguishes processing paths that differ by more than 2 ms. Section 7.2 of [EXPLICIT-MEASUREMENTS] describes masking the RTT with a random reflection delay kept constant across connections for some time. A client can do so without including the added delay in the Response Delay, so that observers attribute it to the network on the client side. The added delay counts toward MAX_RESPONSE_DELAY. Endpoints can send code 15 to withhold their response delay, or omit the transport parameter to expose no delay information. 11. IANA Considerations This document requests the following registrations. 11.1. POEM Delay Version Numbers This document registers the following entries in the "QUIC Versions" registry: Value: 0xTBD3 Status: permanent Specification: This document Change Controller: IETF (iesg@ietf.org) Contact: QUIC Working Group (quic@ietf.org) Notes: POEM Delay Sample Packet Value: 0xTBD4 Status: permanent Specification: This document Change Controller: IETF (iesg@ietf.org) Contact: QUIC Working Group (quic@ietf.org) Notes: POEM Delay Report Packet 11.2. poem_delay_supported Transport Parameter This document registers the following entry in the "QUIC Transport Parameters" registry: Value: 0xTBD Parameter Name: poem_delay_supported Status: Permanent Specification: This document Change Controller: IETF (iesg@ietf.org) Contact: QUIC Working Group (quic@ietf.org) Ihlar & Kühlewind Expires 6 May 2027 [Page 16] Internet-Draft POEM Delay November 2026 Notes: (none) 12. References 12.1. Normative References [INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [QUIC-BIT] Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, August 2022, . [QUICv2] Duke, M., "QUIC Version 2", RFC 9369, DOI 10.17487/RFC9369, May 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [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, . [POEM] Ihlar, L. M. and M. Kühlewind, "A Protocol for Periodic On-path Explicit Measurement", Work in Progress, Internet- Draft, draft-ihlar-poem-quic-01, 20 July 2026, . Ihlar & Kühlewind Expires 6 May 2027 [Page 17] Internet-Draft POEM Delay November 2026 [RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . [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-10, 28 October 2026, . Acknowledgments This work builds on the Delay bit defined in [EXPLICIT-MEASUREMENTS] and the communication model 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 6 May 2027 [Page 18]