Endpoint Handling of SCONE Throughput Advice Across QUIC Path Changes
draft-zhang-scone-migration-advice-00
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 | N. Zhang , Xiaoqing Xu | ||
| Last updated | 2026-06-03 | ||
| 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-zhang-scone-migration-advice-00
SCONE N. Zhang
Internet-Draft X. Xu
Intended status: Informational China Telecom
Expires: 6 December 2026 4 June 2026
Endpoint Handling of SCONE Throughput Advice Across QUIC Path Changes
draft-zhang-scone-migration-advice-00
Abstract
SCONE throughput advice is scoped to the path and direction in which
it is received. When a QUIC connection changes path, the endpoint
can retain an old advice value while that value is no longer
applicable to the active path. This document describes endpoint-
local handling of that transition. It focuses on the distinction
between retained advice and active-path advice, the interval in which
no fresh path-applicable advice is available, and the observability
needed to avoid treating historical advice as current guidance. This
document defines no new SCONE protocol elements, does not modify QUIC
path validation, does not define an application API, and does not
change congestion control behavior.
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."
This Internet-Draft will expire on 6 December 2026.
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.
Zhang & Xu Expires 6 December 2026 [Page 1]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
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. Relationship to Existing SCONE Work . . . . . . . . . . . . . 4
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
4. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Protocol Semantics and Endpoint State . . . . . . . . . . 6
5.2. Path Change and Advice Applicability . . . . . . . . . . 7
5.3. The Advice Gap . . . . . . . . . . . . . . . . . . . . . 7
5.4. Reusing Old Advice on a New Path . . . . . . . . . . . . 7
5.5. Directional Asymmetry . . . . . . . . . . . . . . . . . . 8
5.6. Implementation Ambiguity Examples . . . . . . . . . . . . 8
6. Why This Needs Explicit Handling . . . . . . . . . . . . . . 8
7. Endpoint Handling Guidance . . . . . . . . . . . . . . . . . 9
7.1. General Principle . . . . . . . . . . . . . . . . . . . . 9
7.2. Advice State Model . . . . . . . . . . . . . . . . . . . 9
7.2.1. State Diagram . . . . . . . . . . . . . . . . . . . . 10
7.3. Behavioral Consequences of the Advice Gap . . . . . . . . 12
7.4. Behavior Upon Path Change . . . . . . . . . . . . . . . . 12
7.5. Behavior During the Advice Gap . . . . . . . . . . . . . 13
7.6. Using Existing Signaling Opportunities on New Paths . . . 13
7.7. Arrival of Fresh Advice . . . . . . . . . . . . . . . . . 13
7.8. Advice Expiry on the Active Path . . . . . . . . . . . . 14
7.9. Advice-State Transition Summary . . . . . . . . . . . . . 14
7.10. Worked Example: Cellular to Wi-Fi Migration . . . . . . . 15
7.11. Illustrative Representation of Advice State . . . . . . . 17
8. Manageability Considerations . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Zhang & Xu Expires 6 December 2026 [Page 2]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
1. Introduction
SCONE provides throughput advice to endpoints for a particular
network path and direction. A QUIC [RFC9000] connection, however,
can change the path that carries application traffic. This can occur
during connection migration, interface change, NAT rebinding, or
similar path-level events.
The SCONE protocol already defines the signaling mechanism and the
path-scoped semantics of throughput advice. In particular, advice
received on one path is not assumed to apply to another path. This
document does not restate that rule as a new protocol requirement.
Instead, it describes the endpoint-side state consequences of that
rule.
After a path change, an endpoint can still retain an advice value
that was received on the previous path. That retained value might be
useful for diagnostics, telemetry, or local policy. However,
retaining a value is different from treating that value as current
advice for the active path. If an implementation does not preserve
this distinction, stale advice can be exposed to local adaptation
logic or operational telemetry as if it still represented the active
path.
This document describes the transition between old-path advice and
fresh advice on the active path. It uses the term "advice gap" for
the interval during which previous-path advice is no longer
applicable to the active path and fresh advice for the active path is
not yet available. The advice gap is an endpoint-local condition
used to describe state handling and observability. It is not a new
SCONE protocol state and does not require any new wire-visible
signal.
The guidance in this document is intentionally limited. It does not
define a fallback sending-rate algorithm, does not modify QUIC loss
recovery or congestion control, and does not define how an
application adapts its media rate. Its purpose is to help
implementations avoid conflating three different conditions: explicit
low-rate advice, absence of path-applicable advice, and retained
historical advice.
This document focuses on cases in which application traffic
transitions to a different active path for a single-path QUIC
connection. Multipath-specific handling is outside the scope of this
document.
Zhang & Xu Expires 6 December 2026 [Page 3]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
2. Relationship to Existing SCONE Work
The SCONE protocol [SCONE-PROTOCOL] defines the wire mechanism for
communicating throughput advice and the semantics of that advice. It
also describes opportunities for endpoints to send SCONE packets on a
path so that network elements can provide advice. This document does
not change the SCONE protocol, does not add a new signaling trigger,
and does not define a new requirement for network elements.
The SCONE applicability and manageability document [SCONE-APPMAN]
discusses broader deployment, operational, and monitoring
considerations. This document is narrower. It focuses only on
endpoint-visible advice-state transitions caused by QUIC path
changes.
The specific gap addressed by this document is the implementation
boundary between the protocol semantics of path-scoped advice and the
endpoint's local representation of advice state. An implementation
might store an old advice value, expose advice to an application
component, log advice for operations, or apply local policy based on
advice. This document describes how those uses can remain distinct
from current active-path advice after a path change.
This document is intended as implementation and manageability
guidance. If the working group determines that some of this guidance
belongs in the SCONE protocol or applicability and manageability
documents, the text here can be used as input to that discussion.
3. Conventions and Terminology
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.
old path: A path that previously carried application data for the
QUIC connection and for which throughput advice had been received.
new path: A path that has become active, or is becoming active, for
the same QUIC connection after migration or path re-establishment.
fresh advice: Throughput advice that is applicable to the currently
active path and remains valid according to the semantics defined
by the SCONE protocol.
stale advice: Throughput advice that is retained by an endpoint but
Zhang & Xu Expires 6 December 2026 [Page 4]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
is no longer known to be applicable to the currently active path,
for example because it was received on a previous path.
advice gap: An endpoint-local transition condition during which
advice associated with a previous path is no longer applicable to
the active path, while fresh advice for the active path is not yet
available. An advice gap is not a new SCONE protocol state.
path re-establishment: A transition in which endpoint traffic begins
using a different path for the same QUIC connection, whether due
to migration, interface change, rebinding, or similar path-level
events.
historical advice: Advice information retained by an endpoint after
it ceases to be known to apply to the active path. Historical
advice can be retained for diagnostics, telemetry, or local
policy, but it is not current advice for the active path.
active-path advice state: The endpoint's internal representation of
whether fresh SCONE advice is currently available for the active
path and direction. This is an implementation concept and is not
a wire-visible SCONE field.
path context: An endpoint-local representation of the network path
to which advice applicability is associated. This document does
not define a wire-visible path identifier.
4. Scope and Non-Goals
This document is limited to endpoint handling guidance for SCONE
throughput advice across QUIC path changes.
This document does not:
* define any new SCONE packet format, frame, capsule, transport
parameter, or other protocol element;
* define any application-facing or browser-facing API;
* modify QUIC loss recovery or congestion control;
* define a multipath scheduling algorithm; or
* require a network element to retain, transfer, or reinterpret
advice across paths.
Zhang & Xu Expires 6 December 2026 [Page 5]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
This document also does not require an endpoint to compute a specific
fallback sending rate during the advice gap. Such policies remain an
implementation matter, subject to existing transport behavior,
congestion control, application adaptation logic, and deployment
needs.
This document does not define a normative endpoint state machine.
The states and transitions described here are implementation-facing
distinctions that help prevent stale or historical advice from being
consumed as current active-path advice.
The manageability considerations in this document are limited to
events created by path changes and advice transitions at endpoints.
They complement, rather than replace, more general SCONE deployment
and logging guidance in [SCONE-APPMAN].
This document describes a minimum set of endpoint-side distinctions
that are useful across path changes: whether advice is fresh, stale,
expired, absent, or retained only as historical advice; whether the
endpoint is in an advice gap for a given direction; and when that
advice gap begins and ends.
5. Problem Statement
5.1. Protocol Semantics and Endpoint State
The protocol-level rule is that throughput advice is scoped to the
path and direction for which it is received. The implementation
question is how an endpoint represents that rule after a path change.
This distinction matters because a stored advice value can have
several different uses inside an endpoint.
For example, the value can be retained for diagnostics, reported
through telemetry, made visible to a local adaptation component, or
used by local policy. These uses are not equivalent. A value that
is safe to retain as historical information is not necessarily safe
to expose as current active-path advice.
The problem addressed by this document is therefore not how to
transfer advice from one path to another. It is how to avoid
confusing retained old-path advice with fresh advice for the active
path.
Zhang & Xu Expires 6 December 2026 [Page 6]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
5.2. Path Change and Advice Applicability
SCONE throughput advice is meaningful only in the context in which it
was generated. When a QUIC endpoint migrates a connection from one
path to another, advice associated with the old path cannot be
assumed to remain applicable to the new path. The bottleneck, access
network, and traffic treatment on the new path can differ from those
of the old path.
This creates a transition condition distinct from formal expiry.
Advice can cease to be applicable to the active path when the path
changes, while protocol-defined expiry remains a separate condition.
These conditions need not coincide.
5.3. The Advice Gap
In practice, a new path can start carrying application data before
fresh SCONE advice has arrived for that path. This creates an advice
gap: advice associated with the previous path is no longer applicable
to the active path, while fresh advice for the active path is not yet
available. This condition is especially visible when:
* migration occurs across access technologies;
* the new path was not previously active;
* signaling cadence is coarse relative to path-change timing; or
* the endpoint begins using the new path for application data as
soon as QUIC path validation permits.
5.4. Reusing Old Advice on a New Path
Reusing old advice on a new path can be too conservative. If the new
path offers a higher achievable rate than the old path, carrying
forward prior advice can unnecessarily suppress endpoint sending
behavior.
Reusing old advice can also be too aggressive. If the new path is
narrower or is subject to different policy treatment, carrying
forward prior advice can cause the endpoint to act on guidance that
no longer reflects current path conditions.
Zhang & Xu Expires 6 December 2026 [Page 7]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
5.5. Directional Asymmetry
SCONE advice is directional. Following a connection migration, fresh
advice for one direction can become available before fresh advice for
the opposite direction. As a result, an endpoint can simultaneously
hold fresh advice for one direction and stale or absent advice for
the other.
This can require implementations to track advice transitions on a
per-direction basis where applicable.
5.6. Implementation Ambiguity Examples
The transition described above can lead to materially different
endpoint behavior if implementations do not preserve a clear
distinction between stored advice values and active-path
applicability.
For example, one implementation might retain previously received
advice and continue to surface it to a local adaptation or policy
module after migration, effectively treating cached old-path advice
as if it still constrained the active path. Another implementation
might clear all advice-related state immediately upon path change. A
third implementation might retain the value internally but correctly
mark the active path as having no current advice.
These behaviors are not equivalent. They can lead to different
sending decisions, different policy outcomes, and different telemetry
interpretations even when the same SCONE advice was originally
received.
A similar ambiguity can arise when advice is directional. Following
migration, fresh advice for one direction might become available
before the other. An implementation that models advice state only
once per connection can conflate those cases, while an implementation
that tracks advice state per direction can preserve the distinction.
6. Why This Needs Explicit Handling
The rule that old-path advice is not fresh advice for a new path is
simple. However, the consequences of that rule are not always
captured by a single stored variable. An endpoint might store the
last received advice value, an expiry time, the path on which it was
received, an application-facing estimate, and telemetry fields. If
those fields are not updated consistently after a path change,
different components can observe different interpretations of the
same advice value.
Zhang & Xu Expires 6 December 2026 [Page 8]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
This creates several implementation risks. First, absence of current
path-applicable advice can be confused with explicit low-rate advice.
Second, retained historical advice can be exposed to local policy or
application adaptation logic as if it were current guidance. Third,
telemetry can report that advice is present even when no fresh advice
is available for the active path. Fourth, per-direction differences
can be lost if advice state is tracked only once per connection.
Explicit endpoint handling is therefore useful even when no new
protocol mechanism is required. It provides a common way to describe
the transition from fresh advice to no fresh active-path advice, and
from no fresh active-path advice back to fresh advice when a new
signal is received. It also gives implementations and operators
observable events that can be used to diagnose whether stale advice
was accidentally reused across a path change.
7. Endpoint Handling Guidance
7.1. General Principle
An endpoint that changes to a new QUIC path SHOULD NOT treat advice
associated with the old path as fresh advice for the new path, unless
fresh advice has been received that is applicable to the new path.
This does not imply that the endpoint needs to delete old advice. An
implementation can retain old advice as historical information for
diagnostics, telemetry, or local policy. The important requirement
is that retained historical advice remains distinguishable from
current active-path advice.
In particular, the endpoint needs to preserve the distinction between
three conditions: current active-path advice is available; no current
active-path advice is available; and an old advice value is retained
but no longer applicable to the active path.
7.2. Advice State Model
For endpoint handling across a path change, implementations need to
distinguish the value of previously received advice from its
applicability to the active path. This distinction can be
represented in different ways. This document does not require a
specific data structure or state machine.
For the relevant direction, an implementation can usefully
distinguish at least the following conditions:
* fresh advice: advice is available, has not expired, and is known
to apply to the active path;
Zhang & Xu Expires 6 December 2026 [Page 9]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
* stale advice: advice information is retained, but is not known to
apply to the active path;
* expired advice: advice that was previously fresh for the active
path is no longer fresh due to expiry;
* absence of advice: no fresh advice is available for the active
path; and
* advice gap: a path-change transition during which previous-path
advice is no longer applicable to the active path and fresh advice
for the active path is not yet available.
The advice gap is not a replacement for the active-path advice state.
It is a transition condition that explains why the endpoint currently
has no fresh advice for the affected active path and direction.
These distinctions are useful because the same stored advice value
can be safe to retain for diagnostics but unsafe to consume as
current active-path guidance.
7.2.1. State Diagram
Zhang & Xu Expires 6 December 2026 [Page 10]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
+-----------------------+
| No Advice |
| (Initial / Reset) |
+-----------+-----------+
|
| Fresh advice arrives
| on active path
|
v
+-----------------------+
| Fresh Advice |<---------+
| (Active Path) | |
+-----------+-----------+ |
| |
| Path changes | Fresh advice arrives
v | on new path
+-----------------------+ |
| Advice Gap |----------+
| (New Path, No |
| Fresh Advice) |
+-----------+-----------+
|
| No fresh advice arrives;
| retained advice expires
|
v
+-----------------------+
| No Fresh Active-Path |
| Advice |
| (Active Path) |
+-----------------------+
Figure 1
Figure 1 illustrates a simplified view of active-path advice-state
transitions on a per-direction basis. It is not intended to
represent all retained internal state. In particular, historical
advice may be retained separately from the active-path advice state
shown here.
The transitions shown are: initial receipt of fresh advice; path
change leading to an advice gap; receipt of fresh advice on the new
path ending the advice gap; and loss of fresh active-path advice
without immediate replacement. An implementation may preserve finer
distinctions internally, including separate expired and absent
conditions, so long as it preserves at least the behavioral
distinctions required by this document.
Zhang & Xu Expires 6 December 2026 [Page 11]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
7.3. Behavioral Consequences of the Advice Gap
The advice gap is not merely a bookkeeping condition. Once an
endpoint determines that previously received advice is no longer
applicable to the active path, SCONE-related state needs to be
interpreted differently by the endpoint and by any local policy logic
that consumes that state.
In particular, for the affected direction, the endpoint SHOULD ensure
that absence of current path-applicable advice is distinguishable
from explicit low-rate advice. It should also ensure that any
retained historical advice is not surfaced to local policy or upper-
layer components as if it were current advice for the active path.
Entering an advice gap therefore changes not only the label attached
to stored advice, but also the conditions under which SCONE-related
state can be consumed as current path guidance.
7.4. Behavior Upon Path Change
When an endpoint determines that a different path is becoming active
for a QUIC connection, the following handling applies for each
affected direction:
1. The endpoint disassociates advice that was received for the old
path from the active-path advice state of the new path.
2. The endpoint stops representing old-path advice as fresh advice
for the new path, even if it retains the advice value or related
metadata locally.
3. Unless fresh advice is already available for the new path, the
endpoint marks the new path as being in an advice gap for the
affected direction.
4. During that interval, the endpoint treats the new path as having
no current SCONE advice for the affected direction.
5. The endpoint can retain prior advice as historical advice for
diagnostics, telemetry, or local implementation policy, provided
that such retained state remains distinct from active-path advice
state.
This guidance does not require immediate deletion of all previously
received advice information. It requires a change in applicability:
advice that was fresh for the old path is no longer presumed fresh
for the active path after the path change.
Zhang & Xu Expires 6 December 2026 [Page 12]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
7.5. Behavior During the Advice Gap
The following guidance applies while the endpoint remains in the
advice-gap condition for a direction.
During the advice gap, the endpoint has no current path-applicable
SCONE advice for the affected direction. This condition is different
from receiving explicit low-rate advice. It is also different from
having never received advice, because the endpoint can retain
previous-path advice as historical information.
Accordingly, an endpoint SHOULD NOT apply old-path advice as active
advice for the new path. It SHOULD NOT combine stale or historical
advice with fresh active-path advice in a way that represents them as
belonging to the same path context. It SHOULD NOT expose stale or
historical advice to local policy or upper-layer components as if it
were fresh advice for the active path.
An endpoint can retain historical advice for diagnostics, telemetry,
or local heuristics. Any such retained information remains
historical and needs to stay distinguishable from fresh advice for
the active path.
7.6. Using Existing Signaling Opportunities on New Paths
The SCONE protocol allows endpoints to send SCONE packets on a path,
subject to the rules defined by that protocol. When an endpoint
supports SCONE and performs QUIC path validation, existing SCONE
signaling opportunities on the new path can give network elements an
earlier opportunity to provide fresh advice for that path.
This document does not define a new signaling trigger and does not
alter QUIC path validation. It only notes that using already defined
signaling opportunities can reduce the duration of operating without
fresh path-applicable advice after a path change.
7.7. Arrival of Fresh Advice
When fresh advice becomes available for the active path, the endpoint
SHOULD:
1. update its active-path advice state for the relevant direction;
2. mark the advice gap as ended for that direction; and
3. thereafter apply the fresh advice according to the normal rules
of the SCONE protocol.
Zhang & Xu Expires 6 December 2026 [Page 13]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
An endpoint SHOULD NOT combine, average, or otherwise merge fresh
advice for the active path with stale or historical advice retained
from the old path as if they referred to the same path context.
Fresh advice can arrive at different times for different directions.
Implementations SHOULD therefore manage advice-gap entry, advice-gap
exit, and fresh-advice state on a per-direction basis where
applicable.
7.8. Advice Expiry on the Active Path
If advice for the currently active path expires before replacement
advice is received, the endpoint SHOULD stop treating that advice as
fresh advice for the active path.
After expiry, the endpoint no longer has fresh path-applicable advice
for that direction on the active path. In that respect, expiry and
path change can lead to a similar operational condition: the endpoint
is again operating without fresh active-path advice.
However, expiry on the active path and path change to a different
active path are distinct events and SHOULD remain distinguishable for
observability and local policy.
7.9. Advice-State Transition Summary
This subsection restates, in summary form, the minimum endpoint-
visible state transitions and corresponding handling outcomes
described in the preceding subsections.
Zhang & Xu Expires 6 December 2026 [Page 14]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
+=================+=============+================================+
| Event | Resulting | Endpoint Handling Outcome |
| | Condition | |
+=================+=============+================================+
| Path change, no | Advice gap | Disassociate old-path advice |
| fresh advice on | | from active-path advice state; |
| new path | | treat new path as having no |
| | | current SCONE advice |
+-----------------+-------------+--------------------------------+
| Path change, | Fresh | Switch active-path advice |
| fresh advice | advice on | state to the new path and |
| already | new path | direction |
| available | | |
+-----------------+-------------+--------------------------------+
| Fresh advice | Advice gap | Update active-path advice |
| arrives during | ends | state; mark gap as ended for |
| advice gap | | that direction |
+-----------------+-------------+--------------------------------+
| Advice expires | No fresh | Stop treating expired advice |
| on active path | active-path | as fresh advice for the active |
| | advice | path |
+-----------------+-------------+--------------------------------+
Table 1: Endpoint Advice-State Transitions Across Path Changes
7.10. Worked Example: Cellular to Wi-Fi Migration
Unlike the abstract state summary above, this subsection illustrates
one concrete single-path migration timeline and shows how the
distinctions in this document apply in practice.
This example is intended only to illustrate advice-state transitions.
It does not specify how an endpoint computes transport behavior or
application adaptation during the advice gap.
Zhang & Xu Expires 6 December 2026 [Page 15]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
T0: A client establishes a QUIC connection over a cellular
interface (Path A).
T1: A network element on Path A sends SCONE throughput advice:
downstream = 20 Mbps. The endpoint's active-path advice
state for the downstream direction becomes:
{ path=A, direction=downstream, status=fresh, value=20Mbps }
T2: The client migrates the QUIC connection to a Wi-Fi
interface (Path B). Following the path-change handling
described in this document, the endpoint:
- disassociates the Path A advice from active-path
advice state;
- marks the downstream direction as being in an
advice gap; and
- may retain the Path A advice as historical advice.
Active-path advice state becomes:
{ path=B, direction=downstream, status=absent }
The endpoint is now in the advice gap for the downstream
direction.
In this example, that advice-gap condition corresponds
to the downstream active-path advice state being absent
until fresh advice arrives on Path B.
T3: The client sends QUIC PATH_CHALLENGE on Path B. The
endpoint uses existing SCONE signaling opportunities to
provide an early opportunity for network elements on
Path B to supply fresh advice.
T4: A network element on Path B responds with fresh advice:
downstream = 80 Mbps. Upon receiving that fresh advice,
the endpoint:
- updates active-path advice state to:
{ path=B, direction=downstream, status=fresh, value=80Mbps }
- marks the advice gap as ended for the downstream
direction.
Duration of the advice gap: T4 - T2.
Figure 2
This example illustrates both risks identified earlier: carrying
forward old-path advice can be either unnecessarily conservative or
incorrectly aggressive, depending on the new path.
Zhang & Xu Expires 6 December 2026 [Page 16]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
7.11. Illustrative Representation of Advice State
This section provides a purely illustrative example of how the
advice-state distinctions described in this document might be
represented internally. It does not define a required data
structure, API, or implementation architecture.
One possible internal representation for per-direction active-path
advice state is shown below in pseudocode. The path_context field is
endpoint-local and does not define a wire-visible path identifier.
AdviceState {
path_context: LocalPathContext
direction: enum { upstream, downstream }
status: enum { fresh, stale, expired, absent }
value: optional<ThroughputAdvice>
received_time: optional<Timestamp>
expiry_time: optional<Timestamp>
}
For example, after a path change (7.4), an implementation might
update the active-path advice representation by:
1. copy the previous active-path advice state to historical advice,
if retention is useful;
2. set active_advice[direction].path_context to the new path
context;
3. set active_advice[direction].status to absent unless fresh advice
is already available for the new path; and
4. record advice-gap entry for the affected direction if no fresh
advice is available.
Upon receipt of fresh advice on the new path, an implementation might
update that representation by:
1. set active_advice[direction].status to fresh;
2. set active_advice[direction].value to the received throughput
value;
3. set active_advice[direction].received_time to the current time;
4. set active_advice[direction].expiry_time according to the SCONE
protocol semantics; and
Zhang & Xu Expires 6 December 2026 [Page 17]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
5. record advice-gap exit for the affected direction, if the
endpoint was in an advice gap.
These illustrations are provided to aid implementers. Other internal
representations are equally valid so long as they preserve the
distinction between current active-path advice and retained
historical advice.
8. Manageability Considerations
The manageability considerations in this document focus on endpoint-
visible events created by path changes and advice-state transitions.
They complement, rather than replace, more general SCONE deployment
and logging guidance in [SCONE-APPMAN].
Endpoint observability is useful because stale-advice reuse can
otherwise be difficult to diagnose. A flow can appear to have advice
available because an old value remains stored, even though no fresh
advice is available for the active path. Similarly, an application
component might observe a rate value without being able to determine
whether it is current active-path advice or retained historical
information.
Implementations that support SCONE across QUIC path changes can
provide observability for the following questions:
* whether a path change occurred;
* whether the endpoint had fresh advice before the path change;
* whether the endpoint entered an advice gap for a given direction;
* whether old-path advice was retained only as historical advice;
* whether historical advice was kept separate from active-path
advice state;
* when fresh advice became available on the new path; and
* how long the advice gap lasted.
The following table suggests observable events that implementations
can record for manageability purposes. It is a non-normative example
of observability support rather than a required event taxonomy.
Zhang & Xu Expires 6 December 2026 [Page 18]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
+=======================+================+===================+
| Event Name | Trigger | Suggested Log |
| | | Fields |
+=======================+================+===================+
| advice_path_change | Active path | old_path_context, |
| | changes | new_path_context, |
| | | timestamp, |
| | | had_fresh_advice |
+-----------------------+----------------+-------------------+
| advice_gap_start | Endpoint | path_context, |
| | enters advice | direction, |
| | gap | timestamp |
+-----------------------+----------------+-------------------+
| advice_gap_end | Fresh advice | path_context, |
| | received on | direction, |
| | new path | timestamp, |
| | | gap_duration |
+-----------------------+----------------+-------------------+
| advice_expired | Advice expires | path_context, |
| | on active path | direction, |
| | without | timestamp, |
| | replacement | expired_value |
+-----------------------+----------------+-------------------+
| advice_stale_retained | Old advice | old_path_context, |
| | kept as | direction, |
| | historical | retained_value |
+-----------------------+----------------+-------------------+
Table 2: Suggested Observable Events
These event names are illustrative. Implementations are not required
to use these specific names.
Where per-direction advice handling is implemented, these
observations SHOULD be available per direction.
Such observability is useful for verifying that an implementation
does not silently reuse stale advice across path changes, and that
advice-gap handling remains distinct from handling explicit current-
path rate limitation. It can also assist in distinguishing normal
advice transitions, deployment issues, endpoint policy choices, and
cases where the new path does not involve SCONE-capable network
elements.
Zhang & Xu Expires 6 December 2026 [Page 19]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
9. Security Considerations
This document introduces no new protocol mechanism and therefore does
not create a new signaling attack surface beyond that already
considered by SCONE and QUIC.
Incorrect treatment of stale advice as fresh advice can nevertheless
create security-relevant or policy-relevant misbehavior. If stale
high-rate advice is treated as current advice on a narrower or
differently managed new path, the endpoint can behave inconsistently
with the active path's policy or capacity. If stale low-rate advice
is treated as current advice on a wider new path, the endpoint can
unnecessarily degrade application behavior. These are not new
attacks created by this document, but examples of why active-path
applicability needs to remain explicit.
Implementations ought to distinguish clearly between fresh advice,
stale advice, expired advice, absence of advice, and historical
advice retained for diagnostics or local policy. Exposing
operational state that conflates these conditions can lead to
incorrect operational decisions or misleading telemetry.
Logging and telemetry related to path changes can also introduce
privacy considerations if correlated too precisely across interfaces,
networks, or access changes. Implementations ought to apply ordinary
care when exporting such data.
10. Future Work
This document focuses on single-path QUIC connection migration.
Related topics that may merit future work include multipath cases,
interaction with application-level adaptation logic, and handling
when a connection later returns to a previously used path. These
topics are intentionally left outside the present scope.
11. IANA Considerations
This document has no IANA actions.
12. References
12.1. Normative References
[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/info/rfc2119>.
Zhang & Xu Expires 6 December 2026 [Page 20]
Internet-Draft SCONE Advice Across QUIC Path Changes June 2026
[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/info/rfc8174>.
[RFC9000] 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/info/rfc9000>.
[SCONE-PROTOCOL]
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-04, 14 December 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-scone-
protocol-04>.
12.2. Informative References
[SCONE-APPMAN]
Mishra, S., Sarker, Z., Tomar, A., and K. Abbas,
"Applicability & Manageability Considerations for SCONE",
Work in Progress, Internet-Draft, draft-ietf-scone-
applicability-manageability-01, 7 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scone-
applicability-manageability-01>.
Authors' Addresses
N. Zhang
China Telecom
Email: zhangn1130@outlook.com
X. Xu
China Telecom
Email: xuxqietf@foxmail.com
Zhang & Xu Expires 6 December 2026 [Page 21]