| Internet-Draft | SCONE Advice Across QUIC Path Changes | June 2026 |
| Zhang & Xu | Expires 6 December 2026 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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 is limited to endpoint handling guidance for SCONE throughput advice across QUIC path changes.¶
This document does not:¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
+-----------------------+
| 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 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.¶
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.¶
When an endpoint determines that a different path is becoming active for a QUIC connection, the following handling applies for each affected direction:¶
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.¶
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.¶
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.¶
When fresh advice becomes available for the active path, the endpoint SHOULD:¶
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.¶
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.¶
This subsection restates, in summary form, the minimum endpoint-visible state transitions and corresponding handling outcomes described in the preceding subsections.¶
| Event | Resulting Condition | Endpoint Handling Outcome |
|---|---|---|
| Path change, no fresh advice on new path | Advice gap | Disassociate old-path advice from active-path advice state; treat new path as having no current SCONE advice |
| Path change, fresh advice already available | Fresh advice on new path | Switch active-path advice state to the new path and direction |
| Fresh advice arrives during advice gap | Advice gap ends | Update active-path advice state; mark gap as ended for that direction |
| Advice expires on active path | No fresh active-path advice | Stop treating expired advice as fresh advice for the active path |
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.¶
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.
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.¶
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:¶
Upon receipt of fresh advice on the new path, an implementation might update that representation by:¶
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.¶
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:¶
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.¶
| Event Name | Trigger | Suggested Log Fields |
|---|---|---|
| advice_path_change | Active path changes | old_path_context, new_path_context, timestamp, had_fresh_advice |
| advice_gap_start | Endpoint enters advice gap | path_context, direction, timestamp |
| advice_gap_end | Fresh advice received on new path | path_context, direction, timestamp, gap_duration |
| advice_expired | Advice expires on active path without replacement | path_context, direction, timestamp, expired_value |
| advice_stale_retained | Old advice kept as historical | old_path_context, direction, retained_value |
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.¶
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.¶
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.¶
This document has no IANA actions.¶