Endpoint Handling of SCONE Throughput Advice Across QUIC Path Changes

Introduction SCONE provides throughput advice to endpoints for a particular network path and direction. A QUIC 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.

Relationship to Existing SCONE Work The 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 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.

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

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.

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

Problem Statement

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.

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.

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.

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.

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.

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.

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

Endpoint Handling Guidance

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.

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

State Diagram

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.

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.

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:

The endpoint disassociates advice that was received for the old path from the active-path advice state of the new path.
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.
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.
During that interval, the endpoint treats the new path as having no current SCONE advice for the affected direction.
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.

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.

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.

Arrival of Fresh Advice When fresh advice becomes available for the active path, the endpoint SHOULD:

update its active-path advice state for the relevant direction;
mark the advice gap as ended for that direction; and
thereafter apply the fresh advice according to the normal rules of the SCONE protocol.

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.

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.

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. Endpoint Advice-State Transitions Across Path Changes

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

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.

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.

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. received_time: optional expiry_time: optional } ]]> For example, after a path change (), an implementation might update the active-path advice representation by:

copy the previous active-path advice state to historical advice, if retention is useful;
set active_advice[direction].path_context to the new path context;
set active_advice[direction].status to absent unless fresh advice is already available for the new path; and
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:

set active_advice[direction].status to fresh;
set active_advice[direction].value to the received throughput value;
set active_advice[direction].received_time to the current time;
set active_advice[direction].expiry_time according to the SCONE protocol semantics; and
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.

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 . 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. Suggested Observable Events

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.

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.

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.

IANA Considerations This document has no IANA actions.