Standard Communication with Network Elements (SCONE) Protocol
draft-ietf-scone-protocol-08

SCONE                                                         M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                              C. Huitema
Expires: 13 March 2027                              Private Octopus Inc.
                                                        奥 一穂 (K. Oku)
                                                                  Fastly
                                                                M. Joras
                                                                    Meta
                                                                M. Ihlar
                                                                Ericsson
                                                        9 September 2026

     Standard Communication with Network Elements (SCONE) Protocol
                      draft-ietf-scone-protocol-08

Abstract

   This document describes a protocol where on-path network elements can
   communicate their perspective on the maximum sustainable throughput
   for QUIC flows to endpoints.  This throughput advice suggests an
   upper bound on long-term average throughput, independent of and
   complementary to real-time congestion control signals.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://ietf-wg-
   scone.github.io/scone/draft-ietf-scone-protocol.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-scone-protocol/.

   Discussion of this document takes place on the SCONE Working Group
   mailing list (mailto:scone@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/scone/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/scone/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-scone/scone.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Thomson, et al.           Expires 13 March 2027                 [Page 1]
Internet-Draft               SCONE Protocol               September 2026

   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 13 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Independent of Congestion Signals . . . . . . . . . . . .   5
     3.2.  Unspecified Scope . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Per-Flow Signal . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Unidirectional Signal . . . . . . . . . . . . . . . . . .   7
     3.5.  Advisory Signal . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  Application Use of Advice . . . . . . . . . . . . . . . .   8
   4.  Conventions and Definitions . . . . . . . . . . . . . . . . .   9
   5.  SCONE Packet  . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Rate Signals  . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Monitoring Period . . . . . . . . . . . . . . . . . . . .  12
     5.3.  Endpoint Processing of SCONE Packets  . . . . . . . . . .  13
     5.4.  Following Throughput Advice . . . . . . . . . . . . . . .  14
   6.  Negotiating SCONE . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Indicating Support on New Flows . . . . . . . . . . . . .  15
     6.2.  Limitations of Indication . . . . . . . . . . . . . . . .  16
     6.3.  Indications for Migrated Flows  . . . . . . . . . . . . .  16
     6.4.  Avoiding Ossification When Reading the Indicator  . . . .  16

Thomson, et al.           Expires 13 March 2027                 [Page 2]
Internet-Draft               SCONE Protocol               September 2026

   7.  Network Deployment  . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Applying Throughput Advice Signals  . . . . . . . . . . .  17
       7.1.1.  When To Avoid Updating Throughput Advice  . . . . . .  17
       7.1.2.  Ensuring Throughput Advice Availability . . . . . . .  18
     7.2.  Monitoring Flows  . . . . . . . . . . . . . . . . . . . .  18
       7.2.1.  Deployment of Monitoring Functions  . . . . . . . . .  19
       7.2.2.  Flows That Exceed Throughput Advice . . . . . . . . .  19
   8.  Endpoint Usage  . . . . . . . . . . . . . . . . . . . . . . .  20
     8.1.  Providing Opportunities to Apply Throughput Advice
           Signals . . . . . . . . . . . . . . . . . . . . . . . . .  20
     8.2.  Feedback To Sender About Signals  . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     9.1.  Off-Path Adversaries  . . . . . . . . . . . . . . . . . .  22
     9.2.  Fake SCONE Packets  . . . . . . . . . . . . . . . . . . .  23
     9.3.  Damage to Other Protocols . . . . . . . . . . . . . . . .  24
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  24
     10.1.  Passive Attacks  . . . . . . . . . . . . . . . . . . . .  25
     10.2.  Active Attacks . . . . . . . . . . . . . . . . . . . . .  25
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     11.1.  SCONE Versions . . . . . . . . . . . . . . . . . . . . .  26
     11.2.  scone_supported Transport Parameter  . . . . . . . . . .  27
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     12.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   Many networks have known, concrete rate limits, or apply these limits
   by policy to constrain data rates.  This is often done without any
   ability to indicate rate limits to applications.  The result can be
   that application performance is degraded, because throughput limits
   can manifest in ways that are incompatible with the rate estimation
   or congestion control algorithms used at endpoints.

   Having the network indicate what throughput limits apply, in a way
   that is accessible to endpoints, allows applications to use this
   information when adapting their send rate.

   The Standard Communication with Network Elements (SCONE) protocol is
   negotiated by QUIC endpoints.  SCONE provides a means for a network
   to signal its present best estimate for maximum sustainable
   throughput, or throughput advice, associated with the flows of UDP
   datagrams that QUIC exchanges.

Thomson, et al.           Expires 13 March 2027                 [Page 3]
Internet-Draft               SCONE Protocol               September 2026

   Any network function that is able to update the content of UDP
   datagrams qualifies as a network element that can use SCONE packets
   to provide throughput advice to QUIC endpoints.

   Networks with rate limits can use SCONE to send throughput advice to
   cooperating endpoints to limit overall network usage.  Where
   congestion control signals -- such as Explicit Congestion
   Notification (ECN) [ECN], delays and loss -- operate on a time scale
   of a round trip time, throughput advice operates over a much longer
   period.

   This has benefits in some networks as endpoints can adapt network
   usage to better suit network conditions.  For example, radio networks
   and battery-powered devices perform better with short, bursty
   exchanges, rather than constant transmission at a fixed rate.

   For endpoints, SCONE throughput advice makes network policies
   visible, which can reduce wasteful probing beyond those limits.

2.  Overview

   QUIC endpoints can negotiate the use of SCONE by including a
   transport parameter (Section 6) in the QUIC handshake.  Endpoints
   then occasionally send SCONE packets, which are always coalesced with
   ordinary QUIC packets that they send.

   Networks that have rate limiting policies, or known throughput
   constraints, can detect flows that include SCONE packets.  The
   network, via an on-path network element, can indicate a maximum
   sustainable throughput by modifying the SCONE packet as it transits
   the network element.

   The propagation of SCONE packets, including the throughput advice
   that is update by a network element, is shown in Figure 1.

   +--------+       +---------+      +----------+
   |  QUIC  |       | Network |      |   QUIC   |
   | Sender |       | Element |      | Receiver |
   +---+----+       +----+----+      +----+-----+
       |                 |                |
       +--- SCONE(?) --->|  SCONE(advice) |
       |    +QUIC        +---- +QUIC ---->|
       |                 |                |  Validate QUIC packet
       |                 |                |  and record advice
       |                 |                |

                   Figure 1: Propagation of SCONE signal

Thomson, et al.           Expires 13 March 2027                 [Page 4]
Internet-Draft               SCONE Protocol               September 2026

   QUIC endpoints that receive modified SCONE packets observe the
   indicated version, process the QUIC packet, and then record the
   indicated rate.

   Throughput advice only applies to the direction and path for which it
   is received.  A connection that migrates or uses multipath [QUIC-MP]
   cannot assume that throughput advice from one path applies to new
   paths.  Advice for the client-to-server direction and the server-to-
   client direction of each path are independent, and are expected to be
   different, for reasons including asymmetric link capacity and path
   diversity.  Applications can use SCONE in either or both directions
   of each path at the discretion of endpoints.

3.  Applicability

   This protocol can provide throughput advice only for QUIC flows where
   endpoints send SCONE packets (Section 5).

   The operation of the SCONE protocol depends on network elements that
   are able to modify packets as they are forwarded.  This provides
   endpoints strong evidence that the network element has the power to
   apply a rate limiting policy; though see Section 9 for potential
   limitations on this.

   The throughput advice that this protocol carries is independent of
   congestion signals, limited to a single path and UDP packet flow,
   unidirectional, and strictly advisory.

   A companion document [SCONE-MAN] addresses applicability,
   operational, and deployment considerations in more detail.

3.1.  Independent of Congestion Signals

   SCONE throughput advice is not a substitute for congestion feedback
   or congestion control.  They are complementary.  Congestion signals,
   such as acknowledgments or ECN markings [ECN][WHY-ECN], provide real-
   time information on loss and delay for a network path, whereas SCONE
   throughput advice operates over a much longer period.

   A congestion controller needs to detect changed conditions and change
   sending behavior more quickly than SCONE allows.  Congestion signals
   can indicate a throughput limit that is different from the signaled
   throughput advice.

Thomson, et al.           Expires 13 March 2027                 [Page 5]
Internet-Draft               SCONE Protocol               September 2026

   Endpoints cannot assume that the rate indicated in throughput advice
   is achievable if congestion signals indicate otherwise.  Congestion
   could be experienced at a different point on the network path than
   the network element that signals throughput advice.  Therefore,
   endpoints need to respect the send rate constraints that are set by a
   congestion controller.

   Networks can use SCONE to communicate throughput advice for reasons
   other than rate limiting policies.  For example, a network element in
   an access network could provide reduced throughput advice to guide
   application use of network capacity during periods of unusually high
   usage.

   Throughput advice can indicate temporary increases in available
   capacity or temporarily reduced capacity.  This includes persistent
   overuse, equipment faults, or other transient issues.  Providing
   advice is applicable if increases or reductions are expected to last
   for more than one monitoring period; see Section 5.2.

3.2.  Unspecified Scope

   Just because a network element can set throughput advice, that does
   not prove that the flow can achieve that rate.  Nor is it a
   commitment to providing that throughput.  It is a hint that exceeding
   that rate is unlikely to be successful, from the perspective of a
   specific network element.

   A signal that is sent for a specific flow could apply to a collection
   of flows, rather than a single flow.  The scope of the flows that are
   included is not carried in the signal.

   For instance, policy limits might apply at a network subscription
   level, such that multiple flows receive the same signal and combined
   usage contributes to the shared limit.

   Endpoints can therefore be more confident in the throughput signal as
   an indication of the maximum achievable throughput than as any
   indication of expected throughput.  In addition to endpoints
   respecting congestion signals (see Section 3.1), networks might need
   to monitor and enforce policies, even where applications attempt to
   follow advice (see Section 7.2.2).

   The advised throughput will likely only be achievable when the
   application is the only entity consuming bandwidth in the scope that
   the advice applies to.  In the presence of multiple flows, achievable
   throughput could be lower than what is indicated by the advice, with
   throughput determined by a congestion controller.

Thomson, et al.           Expires 13 March 2027                 [Page 6]
Internet-Draft               SCONE Protocol               September 2026

   This implies that signals can most usefully be applied to a downlink
   flow in access networks, close to an endpoint.  In that case,
   capacity is less likely to be split between multiple active flows.

3.3.  Per-Flow Signal

   The same address tuple (IP version, source and destination IP
   addresses and UDP ports) might be used for multiple QUIC connections.
   A single signal might be lost or only reach a single application
   endpoint.  Network elements can apply SCONE throughput advice to all
   QUIC connections that include SCONE packets to ensure that advice is
   received by all application endpoints.

   The signaled advice applies to the flow of packets on the same
   address tuple for the duration of the current monitoring period,
   unless it is updated earlier or the flow ends; see Section 5.2 for
   details on the monitoring period.

   Rate limiting policies often apply on the level of a device or
   subscription, but endpoints cannot assume that this is the case.  A
   separate signal can be sent for each flow.

   When network elements provide throughput advice to a QUIC flow that
   encapsulates tunneled flows (such as [CONNECT-UDP]) they can only
   provide the advice to the outermost flow.  Endpoints can apply the
   throughput advice to packets in flows that are subsequently
   encapsulated, but following that advice can have privacy
   implications; see Section 10.2.

3.4.  Unidirectional Signal

   Throughput advice is signaled with SCONE packets that are transmitted
   as part of the flow that the advice applies to.  Carrying signals in
   the affected flow, in the same way that ECN signals are conveyed,
   ensures that there is no ambiguity about what flow is affected.
   However, this means that the endpoint that receives throughput advice
   is not the endpoint that needs to adapt its sending behavior.

   A receiving endpoint might need to communicate the value it receives
   to the sending peer in order to ensure that the limit is respected.
   This document does not define how that communication occurs as this
   is specific to the application in use.

Thomson, et al.           Expires 13 March 2027                 [Page 7]
Internet-Draft               SCONE Protocol               September 2026

3.5.  Advisory Signal

   Throughput advice indicates what one part of the network expects to
   be achievable for flows that transit that portion of the network.  It
   is possible that very different throughput is achievable -- either
   higher or lower than the advice -- as determined by congestion
   control.  Endpoints that receive this signal therefore need to treat
   the information as advisory.

   The fact that an endpoint requests throughput advice does not
   necessarily mean that it will adhere to advice; in some cases, the
   endpoint cannot.  For example, a flow could initially be used to
   serve video chunks, with the client selecting chunks of different
   bitrates based on received advice, but later switch to a bulk
   download that cannot be similarly controlled.  Composite flows from
   multiple applications, such as tunneled flows, might only have a
   subset of the involved applications that are capable of handling
   SCONE signals.  Therefore, when a network element detects that
   throughput exceeds the advertised throughput advice, it might apply
   rate limiting.

   Network conditions and rate-limit policies can change in ways that
   make previously signaled advice obsolete.  For example, routing
   changes can cause a flow to move to a different network path.  There
   are no guarantees that updated advice will be sent at such events.

3.6.  Application Use of Advice

   Applications that choose to follow throughput advice do so in the way
   that best suits their needs.

   The most obvious way to follow throughput advice is to inform the
   sending peer of the advice so that the peer can adjust sending rates
   as necessary.  This document does not provide specific guidance on
   how applications might adapt their use of network capacity in
   response to advice.

   Some applications offer options for rate control that can offer
   improved performance when following advice.  For instance, real-time
   and streaming video applications can often dynamically adapt their
   network usage.  Typical HTTP Live Streaming [HLS] or Dynamic Adaptive
   Streaming over HTTP [DASH] clients are provided with manifests that
   allow them to adjust the bitrate and quality of media segments based
   on available network capacity.  Low priority bulk transfer
   applications, such as software updates, might also choose to follow
   advice.

Thomson, et al.           Expires 13 March 2027                 [Page 8]
Internet-Draft               SCONE Protocol               September 2026

   Following throughput advice could reduce the impact of an application
   on other network users, reserves capacity for high-priority
   activities, and could avoid potential enforcement action by the
   network; see Section 7.2.2.

4.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [BCP14] when, and only when, they appear in all capitals, as
   shown here.

   In SCONE:

   *  a "network element" is any device in the network that can produce
      throughput advice.

   *  "Throughput advice" refers the information communicated to
      endpoints by network elements in the form of a rate signal; see
      Section 5.1.

   *  A "monitoring period" is the time over which rate signals apply;
      see Section 5.2.

5.  SCONE Packet

   A SCONE packet is a QUIC long header packet that follows the QUIC
   invariants; see Section 5.1 of [INVARIANTS].

   Figure 2 shows the format of the SCONE packet using the conventions
   from Section 4 of [INVARIANTS].

   SCONE Packet {
     Header Form (1) = 1,
     Reserved (1),
     Rate Signal High Bits (6),
     Version (32) = 0x6f7dc0fd or 0xef7dc0fd,
     Destination Connection ID Length (8),
     Destination Connection ID (0..2040),
     Source Connection ID Length (8),
     Source Connection ID (0..2040),
   }

                       Figure 2: SCONE Packet Format

Thomson, et al.           Expires 13 March 2027                 [Page 9]
Internet-Draft               SCONE Protocol               September 2026

   The most significant bit (0x80) of the packet indicates that this is
   a QUIC long header packet.  The next bit (0x40) is reserved and can
   be set according to [QUIC-BIT].

   The Rate Signal High Bits field consists of the low six bits (0x3f)
   of the first byte.  Together with the most significant bit of the
   Version field, this forms the 7-bit Rate Signal.  Values for the Rate
   Signal are described in Section 5.1.

   The Version field contains either 0x6f7dc0fd or 0xef7dc0fd.  The only
   difference between these two values is the most significant bit,
   which also contributes to the Rate Signal.  All other bits are
   identical, which facilitates detection and modification of SCONE
   packets.

   This packet includes a Destination Connection ID field that is set to
   the same value as other packets in the same datagram; see
   Section 12.2 of [QUIC].

   The Source Connection ID field is set to match the Source Connection
   ID field of any packet that follows.  If the next packet in the
   datagram does not have a Source Connection ID field, which is the
   case for packets with a short header (Section 5.2 of [INVARIANTS]),
   the Source Connection ID field MUST be empty and the Source
   Connection ID Length field MUST be 0.

   SCONE packets MUST be coalesced with other QUIC packets (see
   Section 12.2 of [QUIC]) and MUST be included as the first packet in a
   datagram.  This is primarily to simplify the process of updating
   throughput advice in network elements.  This is also necessary in
   many cases for QUIC versions 1 and 2 because packets with a short
   header cannot precede any other packets.

   A sender MUST NOT include more than one SCONE packet in a datagram.

5.1.  Rate Signals

   A Rate Signal is a 7-bit unsigned integer (0-127).  The high six bits
   are the Rate Signal High Bits, and the least significant bit is the
   most significant bit of the Version field.

   When sent by a QUIC endpoint, the Rate Signal is set to 127.
   Receiving a value of 127 indicates that throughput advice is unknown,
   either because network elements on the path are not providing advice
   or they do not support SCONE.  All other values (0 through 126)
   represent the ceiling of rates advised by the network element(s) on
   the path.

Thomson, et al.           Expires 13 March 2027                [Page 10]
Internet-Draft               SCONE Protocol               September 2026

   Throughput advice follows a logarithmic scale defined as:

   *  Base rate (b_min) = 100 kbit/s (100,000 bits per second)

   *  Bitrate at value n = b_min * 10^(n/20)

   where n is an integer between 0 and 126 represented by the Rate
   Signal.

   Table 1 lists some of the values for signals and the corresponding
   bitrate for each.

Thomson, et al.           Expires 13 March 2027                [Page 11]
Internet-Draft               SCONE Protocol               September 2026

                      +==============+=============+
                      | Bitrate      | Rate Signal |
                      +==============+=============+
                      | 100 kbit/s   | 0           |
                      +--------------+-------------+
                      | 112 kbit/s   | 1           |
                      +--------------+-------------+
                      | 126 kbit/s   | 2           |
                      +--------------+-------------+
                      | 141 kbit/s   | 3           |
                      +--------------+-------------+
                      | 1 Mbit/s     | 20          |
                      +--------------+-------------+
                      | 1.12 Mbit/s  | 21          |
                      +--------------+-------------+
                      | 10 Mbit/s    | 40          |
                      +--------------+-------------+
                      | 11.2 Mbit/s  | 41          |
                      +--------------+-------------+
                      | 100 Mbit/s   | 60          |
                      +--------------+-------------+
                      | 112 Mbit/s   | 61          |
                      +--------------+-------------+
                      | 1 Gbit/s     | 80          |
                      +--------------+-------------+
                      | 1.12 Gbit/s  | 81          |
                      +--------------+-------------+
                      | 10 Gbit/s    | 100         |
                      +--------------+-------------+
                      | 11.2 Gbit/s  | 101         |
                      +--------------+-------------+
                      | 100 Gbit/s   | 120         |
                      +--------------+-------------+
                      | 112 Gbit/s   | 121         |
                      +--------------+-------------+
                      | 199.5 Gbit/s | 126         |
                      +--------------+-------------+
                      | Unknown      | 127         |
                      +--------------+-------------+

                        Table 1: Examples of SCONE
                        signals and corresponding
                                  rates

5.2.  Monitoring Period

   The time over which throughput advice applies is defined to be a
   period of 67 seconds.

Thomson, et al.           Expires 13 March 2027                [Page 12]
Internet-Draft               SCONE Protocol               September 2026

   Protocol participants can use a different period, depending on their
   role.  Senders can limit their send rate over any time period up to
   67 seconds.  Network elements can monitor and apply limits to send
   rates using time period of at least 67 seconds.

   The choice of 67 seconds is a compromise between competing interests.
   Longer periods allow applications more flexibility in terms of how to
   allocate bandwidth over time.  Shorter periods allow networks to
   administer policies more tightly.  A shorter period also allows
   applications to increase send rates sooner when rates increase.

   The choice of 67 seconds, as a prime number, also helps avoid
   synchronization with other periodic effects that are commonly
   measured in whole seconds.  This includes segment length or key frame
   intervals in video applications, but also includes timers for Network
   Address Translation (NAT) devices; see Section 4.3 of [RFC4787].  Any
   repeating phenomenon at a 67 second interval is therefore unlikely to
   be due to other periodic effects.

5.3.  Endpoint Processing of SCONE Packets

   Processing a SCONE packet involves reading the value from the Rate
   Signal field.  However, throughput advice MUST be ignored unless
   another packet from the same datagram is successfully processed.
   Therefore, a SCONE packet always needs to be coalesced with other
   QUIC packets.

   A SCONE packet is defined by the use of the long header bit (0x80 in
   the first byte) and the SCONE protocol version (0x6f7dc0fd or
   0xef7dc0fd in the next four bytes).  The 7-bit Rate Signal can be
   extracted by combining the low 6 bits of the first byte with the most
   significant bit of the version field.  A SCONE packet MUST be
   discarded if the Destination Connection ID is not consistent with
   those coalesced packets, as specified in Section 5.  Similarly, if
   the Source Connection ID is inconsistent, the SCONE packet MAY be
   discarded.

   When discarding a SCONE packet due to inconsistent Connection IDs,
   endpoints MAY also discard the QUIC packets that were coalesced into
   the same datagram.

   A receiver MAY discard a datagram that contains more than one SCONE
   packet.  A receiver MUST discard a SCONE packet if the rate signal is
   unknown (127).

Thomson, et al.           Expires 13 March 2027                [Page 13]
Internet-Draft               SCONE Protocol               September 2026

   If a connection uses multiple Differentiated Services Code Point
   (DSCP) markings [RFC2474], the throughput advice that is received on
   datagrams with one marking might not apply to datagrams that have
   different markings.

5.4.  Following Throughput Advice

   Endpoints that receive throughput advice can advise their peer of the
   limit so that the peer might limit the amount of data it sends over
   any monitoring period (Section 5.2).  Alternatively, the endpoint
   might change its own behavior to effect a similar outcome indirectly,
   which might use flow control or changes to request patterns.

   An endpoint that receives throughput advice might receive multiple
   different values.  If advice is applied by applications, applications
   MUST apply the lowest throughput advice received during any
   monitoring period; see Section 5.2.

   After a monitoring period (Section 5.2) without receiving any
   throughput advice, the previous advice expires.  Endpoints can remove
   any constraints that resulted from the expired throughput advice.
   This does not mean that there are no limits, either in policy or due
   to network conditions, only that these limits are now unknown.  Other
   constraints on usage will still apply, which necessarily includes
   congestion control and might include other, application-specific
   constraints.

   Allowing advice to expire ensures that changes in routing do not
   cause stale advice to persist indefinitely when network elements on a
   new path do not provide advice.

   This approach ensures that network elements are able to reduce the
   frequency with which they send updated signals to as low as once per
   monitoring period.  However, applying signals at a low frequency
   risks endpoints discarding throughput advice if no SCONE packet is
   available for providing updated advice (Section 7.1), or packets
   carrying advice are lost.  Sending the signal multiple times per
   monitoring period increases the likelihood that the signal is
   received.

6.  Negotiating SCONE

   A QUIC endpoint indicates that it is able to receive SCONE packets by
   including the scone_supported transport parameter (0x219e).

Thomson, et al.           Expires 13 March 2027                [Page 14]
Internet-Draft               SCONE Protocol               September 2026

   Each endpoint independently indicates willingness to receive SCONE
   packets.  An endpoint that does not include the scone_supported
   transport parameter can send SCONE packets if their peer includes the
   transport parameter.

   The scone_supported transport parameter MUST be empty.  Receiving a
   non-zero length scone_supported transport parameter MUST be treated
   as a connection error of type TRANSPORT_PARAMETER_ERROR; see
   Section 20.1 of [QUIC].

   This transport parameter is valid for QUIC versions 1 [QUIC] and 2
   [QUICv2] and any other version that recognizes the versions,
   transport parameters, and frame types registries established in
   Sections 22.2, 22.3, and 22.4 of [QUIC].

   Endpoints MUST NOT remember whether the scone_supported transport
   parameter was present on the previous connection when using 0-RTT;
   see Section 7.4.1 of [QUIC].  That is, SCONE packets cannot be sent
   on a connection until the transport parameter is received.

6.1.  Indicating Support on New Flows

   All new flows that are initiated by a client that supports SCONE MUST
   include bytes with values 0xc8 and 0x13 as the last two bytes of the
   payload of the UDP datagrams that commence a new flow, if the
   protocol permits the inclusion of data after packets.

   For example, in QUIC version 1, these datagrams contain QUIC packets
   with a long header (Section 17.2 of [QUIC]).  The UDP datagrams sent
   by a client can contain: one or more QUIC version 1 Initial packets,
   zero or more 0-RTT packets, padding or other data that is discarded
   on receipt, and the indication bytes (0xc8, 0x13) as the final bytes
   of the UDP payload.

   The SCONE indication bytes MUST be sent in every datagram until the
   client receives any datagram from the server, at which point the
   client can reasonably expect that the indication was received.

   A client that uses a QUIC version that sends length-delimited packets
   during the handshake, which includes QUIC versions 1 [QUIC] and 2
   [QUICv2], can include an indicator of SCONE support outside of the
   QUIC packets at the end of datagrams that start a flow.  The
   handshakes of these protocols ensures that the indication can be
   included in every datagram the client sends until it receives a
   response -- of any kind -- from the server.

Thomson, et al.           Expires 13 March 2027                [Page 15]
Internet-Draft               SCONE Protocol               September 2026

6.2.  Limitations of Indication

   This indication does not mean that SCONE signals will be respected,
   only that the client is able to negotiate SCONE.  A server might not
   support SCONE and either endpoint might choose not to send SCONE
   packets.  Finally, applications might be unable to apply throughput
   advice or choose to ignore it.

   There is a non-negligible risk of collision with other protocols or
   even QUIC usage without SCONE indications.  The indicator is just two
   bytes, which could be sent by chance on non-SCONE flows.  This means
   that the indication alone is not sufficient to indicate that a flow
   is QUIC with the potential for SCONE support.

   Despite these limitations, having an indication might allow network
   elements to change their starting posture with respect to their
   enforcement of their rate limit policies.

6.3.  Indications for Migrated Flows

   In QUIC version 1 and 2, the two byte indicator (Section 6.1) cannot
   be used on migration to a new path.

   Sending a SCONE packet for the first few packets on a new path gives
   network elements on that path the ability to recognize the flow as
   being able to receive throughput advice.  The SCONE packet also gives
   the network element an opportunity to provide throughput advice for
   the new flow.

   To enable this indication, even if an endpoint would not otherwise
   send SCONE packets, endpoints can send a SCONE packet any time they
   send a QUIC PATH_CHALLENGE or PATH_RESPONSE frame.  This applies to
   both client and server endpoints, but only if the peer has sent the
   transport parameter; see Section 6.

6.4.  Avoiding Ossification When Reading the Indicator

   A network element could classify all 5-tuples where the first
   observed UDP datagram ends in the indicator bytes as potential SCONE.
   A network element MAY apply further criteria to further reduce the
   set of flows that are identified as potentially supporting SCONE,
   reducing the likelihood of false positives.  However, it SHOULD NOT
   apply criteria that reduce the ability of new QUIC versions to employ
   SCONE.  SCONE operates independently of any specific QUIC version, so
   any criteria should consult the QUIC version invariants in
   [INVARIANTS].

Thomson, et al.           Expires 13 March 2027                [Page 16]
Internet-Draft               SCONE Protocol               September 2026

7.  Network Deployment

   QUIC endpoints can enable the use of the SCONE protocol by sending
   SCONE packets (Section 5).  Network elements can then update the Rate
   Signal field (Section 7.1) according to their policies.

7.1.  Applying Throughput Advice Signals

   A network element detects a SCONE packet by observing that a packet
   has a QUIC long header and one of the SCONE protocol versions
   (0x6f7dc0fd or 0xef7dc0fd).

   A network element then conditionally replaces the most significant
   bit of the Version field and the Rate Signal High Bits field with
   values of its choosing.

   A network element might receive a packet that already includes a rate
   signal.  The network element replaces the rate signal if it wishes to
   signal a lower value for throughput advice; otherwise, the original
   values are retained, preserving the signal from the network element
   with the lower policy.  A network element MUST NOT replace a rate
   signal with a higher or unknown value.

   The following pseudocode indicates how a network element might detect
   a SCONE packet and replace the existing rate signal (packet_signal)
   with a new rate signal (target_signal) that encodes the throughput
   advice of this network element.

   is_long = packet[0] & 0x80 == 0x80
   packet_version = ntohl(packet[1..5])
   if is_long and (packet_version & 0x7fffffff) == SCONE_VERSION_BITS:
     packet_signal = ((packet[0] & 0x3f) << 1) | (packet_version >> 31)
     if target_signal < packet_signal:
       packet[0] = (packet[0] & 0xc0) | (target_signal >> 1)
       packet[1] = (packet[1] & 0x7f) | ((target_signal & 1) << 7)

   Once the throughput advice is updated, the network element updates
   the UDP checksum for the datagram; see [RFC1141].

7.1.1.  When To Avoid Updating Throughput Advice

   A network element MUST NOT alter datagrams to add SCONE packets or
   synthesize datagrams that contain SCONE packets.  The latter will not
   be accepted and the former, even if they do not exceed the path MTU
   as a result, can be detected by applications and could be ignored.
   This document does not define a mechanism to support detection, but
   one might be added in future.

Thomson, et al.           Expires 13 March 2027                [Page 17]
Internet-Draft               SCONE Protocol               September 2026

   Network elements MUST only update the content of datagrams on a given
   address tuple a few times each monitoring period.  Network elements
   MAY update more often immediately after a change in their throughput
   advice, to reduce the reaction time from senders.  If too many
   datagrams are altered, that could interfere with UDP protocols that
   are not QUIC; see Section 9.3.

7.1.2.  Ensuring Throughput Advice Availability

   To avoid throughput advice expiring, a network element needs to
   ensure that it updates throughput advice in SCONE packets with no
   more than a monitoring period (Section 5.2) between each update.
   Because this depends on the availability of SCONE packets and packet
   loss can cause signals to be missed, network elements might need to
   update more often.  Ideally, network elements update advice in SCONE
   packets at least twice per monitoring period, to match endpoint
   behavior (see Section 8.1).

   At the start of a flow, network elements are encouraged to update the
   rate signal of the first few SCONE packets it observes so that
   endpoints can obtain throughput advice early.

   Senders that send a SCONE packet or network elements that update
   SCONE packets every 20–30 seconds are likely sufficient to ensure
   that throughput advice is not lost.  To reduce the risk of
   synchronization across multiple senders, which could cause network
   elements to miss updates, senders can include a small random delay.

7.2.  Monitoring Flows

   Providing throughput advice is optional for any network.  A network
   that updates SCONE packets to provide throughput advice might, also
   optionally, choose to monitor flows to determine whether applications
   are following advice.

   This section outlines a method that a network element could use to
   determine whether a flow exceeds the value from provided throughput
   advice.  Network deployments that choose to monitor are free to
   follow any monitoring regime that suits their needs.

   This documented approach to monitoring is largely illustrative; there
   is no interoperability impact from choosing an alternative approach.
   However, monitoring any more strictly than the following could mean
   that an application might be incorrectly classified as not following
   advice.  A looser monitoring approach, such as monitoring over a
   longer time window than the monitoring period (67s) or using a higher
   rate than is signaled, has no risk of incorrect classification.

Thomson, et al.           Expires 13 March 2027                [Page 18]
Internet-Draft               SCONE Protocol               September 2026

   When a network changes the throughput advice it intends to provide,
   applications need time to adjust their sending behavior.  As a
   result, any monitoring needs to allow time for SCONE packets to be
   updated, for those packets to be received by endpoints, and for
   applications to adapt.

   A network element can then monitor affected flows to determine
   whether the provided throughput advice was followed.

   The simplest monitoring approach bases monitoring on the maximum
   value that the network element was configured to apply to SCONE
   packets during the preceding two monitoring periods.  This allows an
   additional monitoring period to compensate for additional delays as
   SCONE packets are not delivered reliably.  Relative to an additional
   monitoring period, other delays in propagating throughput advice are
   expected to be negligible.  If the network element cannot update the
   throughput advice in every SCONE packet (or can only do so
   periodically), a longer period might be used.

7.2.1.  Deployment of Monitoring Functions

   Any monitoring and policy enforcement could be implemented in
   different network elements than the ones that signal throughput
   advice.  This enables more flexible allocation of responsibilities
   between nodes in the same administrative domain.

   SCONE packets can cross administrative boundaries, which means that
   network elements might observe throughput advice on SCONE packets
   that have transited other networks.  A network element MUST NOT
   enforce throughput limits based on throughput advice that is observed
   in SCONE packets received from other entities.  Any enforcement
   action needs to be the result of configuration or other authorized
   administrative action, not unauthenticated network signals.  Unlike
   endpoints, network elements do not have the capability to validate
   other QUIC packets contained in the same datagram; see Section 9.2.

7.2.2.  Flows That Exceed Throughput Advice

   A network could deploy policy enforcement that drops or delays
   packets to ensure that applications do not exceed throughput limits
   set in policy.

   SCONE allows networks to provide advice to applications, so that
   there is less need to enforce throughput limits on flows.  Strict
   enforcement through dropping or delaying packets can be inefficient
   and lead to poor application performance.

Thomson, et al.           Expires 13 March 2027                [Page 19]
Internet-Draft               SCONE Protocol               September 2026

   Some applications will not support SCONE.  Other applications either
   will not or cannot follow throughput advice.

   Networks can monitor flows to determine if applications follow
   advice; see Section 7.2.  A network could choose to either disable or
   loosen policy enforcement for flows where SCONE is active, but re-
   enable or tighten enforcement if monitoring indicates that throughput
   advice is not being respected.

8.  Endpoint Usage

   The SCONE protocol defines two versions (0x6f7dc0fd and 0xef7dc0fd)
   that combined carry throughput advice that covers a range of bitrates
   between 100 kbit/s and 199.5 Gbit/s.

8.1.  Providing Opportunities to Apply Throughput Advice Signals

   Endpoints that wish to offer network elements the option to provide
   throughput advice signals can send SCONE packets at any time.  This
   is a decision that a sender makes when constructing datagrams.

   As specified in Section 5, endpoints include a SCONE packet as the
   first packet in a datagram, coalesced with additional packets.

   Upon confirmation that the peer is willing to receive SCONE packets,
   an endpoint SHOULD include SCONE packets in the first few UDP
   datagrams that it sends.  Doing so increases the likelihood of
   eliciting early throughput advice from network elements, allowing
   applications to apply that advice from the early stages of the data
   transfer.

   After that, endpoints that seek to receive throughput advice on a
   flow MUST send a SCONE packet at least twice each monitoring period;
   see Section 5.2.

   Sending SCONE packets more often might be necessary to:

   Avoid missing advice:  If SCONE packets are not sent, updated, and
      received for an entire monitoring period, an application might
      assume that no throughput advice is being provided.

   Reduce latency:  The time between SCONE packets determines the
      maximum delay between changes in throughput advice and when that
      advice can be received and acted upon.

   A sender can track the receipt of the coalesced QUIC packet and send
   another SCONE packet when loss is detected.  However, it is likely
   simpler to send SCONE packets more often.

Thomson, et al.           Expires 13 March 2027                [Page 20]
Internet-Draft               SCONE Protocol               September 2026

   Sending a SCONE packet every 20–30 seconds is likely sufficient to
   ensure that throughput advice is not lost, though endpoints might
   send a packet every few seconds to improve responsiveness.  This
   period could be determined by how quickly an application is able to
   respond to a change in throughput advice.

   For example, a streaming application that fetches video segments that
   are 5 seconds in length might send SCONE packets on a similar
   cadence.  A real-time conferencing application might send more often.
   In either case, the length of the monitoring period (Section 5.2)
   limits how fast any application can react.

   Though sending SCONE packets more than once each round trip time
   might help reduce exposure to packet loss, it is better to spread
   updates over time rather than to send multiple SCONE packets in less
   frequent bursts.

   The main cost associated with sending SCONE packets is the reduction
   in available space in datagrams for application data.

   A network element that wishes to signal updated throughput advice
   waits for the next SCONE packet in the desired direction; see
   Section 7.1.

8.2.  Feedback To Sender About Signals

   Information about throughout advice is intended for the sending
   application.  Any signal from network elements can be propagated to
   the receiving application using an implementation-defined mechanism.

   This document does not define a means for indicating what was
   received.  The expectation is that any signal is propagated to the
   application for handling, rather than being handled automatically by
   the transport layer.  How a receiving application communicates
   throughput advice to a sending application will depend on the
   application in use.

   Different applications can choose different approaches.  For example,
   in an application where a receiver drives rate adaptation, it might
   not be necessary to define additional signaling.

Thomson, et al.           Expires 13 March 2027                [Page 21]
Internet-Draft               SCONE Protocol               September 2026

   A sender can use any acknowledgment mechanism provided by the QUIC
   version in use to learn whether datagrams containing SCONE packets
   were likely received.  This might help inform whether to send
   additional SCONE packets in the event that a datagram is lost.  For
   instance, if a UDP datagram carrying both a SCONE packet and an ack-
   eliciting QUIC packet is acknowledged, the sender knows the SCONE
   packet was also received.  However, rather than relying solely on
   transport-layer acknowledgments, an application-layer mechanism might
   better indicate what has been received and acted upon.

   SCONE packets could be stripped from datagrams in the network, which
   cannot be reliably detected.  This could result in a sender falsely
   believing that no network element applied throughput advice.  Senders
   will therefore proceed as though there was no advice.

9.  Security Considerations

   SCONE throughput advice is not authenticated.  Throughput advice
   might be incorrectly set in order to encourage endpoints to behave in
   ways that are not in their interests.  Endpoints can ignore limits,
   though that can have consequences; see Section 7.2.2.  The congestion
   controller employed by a sender provides real-time information about
   the rate at which the network path is delivering data.

   Similarly, if there is a strong need to ensure that throughput advice
   is respected, network elements cannot assume that the signaled advice
   will be respected by endpoints.

9.1.  Off-Path Adversaries

   The modification of packets provides endpoints proof that a network
   element is in a position to drop datagrams and could apply a rate
   limit policy.  Section 8.1 states that endpoints only accept signals
   if the datagram contains a packet that it accepts to prevent an off-
   path attacker from inserting spurious throughput advice.

   Some off-path attackers could be able to both observe traffic and
   inject packets.  Attackers with such capabilities could observe
   packets sent by an endpoint, create datagrams coalescing an arbitrary
   SCONE packet and the observed packet, and send these datagrams such
   that they arrive at the peer endpoint before the original packet.
   Spoofed packets that seek to advertise a higher limit than might
   otherwise be permitted also need to bypass any rate limiters.  The
   attacker will thus get arbitrary SCONE packets accepted by the peer,
   with the result being that the endpoint receives a false or
   misleading rate limit.

Thomson, et al.           Expires 13 March 2027                [Page 22]
Internet-Draft               SCONE Protocol               September 2026

   The recipient of throughput advice therefore cannot guarantee that
   the signal was not generated by an on-path network element.

   The capabilities required of an off-path attacker are substantially
   similar to those of on path elements.  An off-path attacker can
   generate throughput advice that will be accepted by an endpoint if it
   has the ability to damage packets in a way that could be able to
   affect throughput capacity of the flow.  The one exception is an off-
   path attacker that is only capable of generating spoofed copies of
   packets with modified throughput rates that reach endpoints ahead of
   the original.

9.2.  Fake SCONE Packets

   Attackers that can inject packets could compose arbitrary "SCONE-
   like" packets by selecting a pair of IP addresses and ports, an
   arbitrary rate signal, a valid SCONE version number, an arbitrary
   "destination connection ID", and an arbitrary "source connection ID".
   A coalesced "1RTT" packet will start with a plausible first octet,
   and continue with the selected destination connection ID followed by
   a sufficiently long series of random bytes, mimicking the content of
   an encrypted packet.

   Endpoints will reject such packets because they do not contain valid
   QUIC packets, but network elements cannot detect this.  All the
   network elements between the injection point and the destination will
   have to process these packets.

   Attackers could send a high volume of these "fake" SCONE packets in a
   denial of service (DOS) attempt against network elements.  The attack
   will force the intermediaries to process the fake packets.  If
   network elements are keeping state for ongoing SCONE flows, this
   might exhaust memory resources.  The mitigation is the same as for
   other distributed DOS attacks: limit the rate of SCONE packets that a
   network element is willing to process; possibly, implement logic to
   distinguish valid SCONE packets from fake packets; or, use generic
   protection against Distributed DOS attacks.

   Attackers could also try to craft the fake SCONE packets in ways that
   trigger a processing error at network elements.  For example, they
   might pick connection identifiers of arbitrary length.  Network
   elements can mitigate these attacks with an implementation that fully
   conforms to the specification of Section 5.

Thomson, et al.           Expires 13 March 2027                [Page 23]
Internet-Draft               SCONE Protocol               September 2026

9.3.  Damage to Other Protocols

   Network elements that update SCONE packet fields might do that for
   datagrams exchanged in other protocols.  If the first five bytes of
   the datagram match the QUIC long header byte and SCONE version, the
   network element might modify the signal, resulting in damage to those
   protocols.

   The most serious damage occurs when every datagram matches and is
   subsequently modified, because that could mean that the protocol is
   effectively unable to operate end-to-end.

   To avoid unrecoverable damage to non-QUIC protocols, network elements
   only update a limited number of datagrams in each monitoring period;
   see Section 7.1.

   In addition, some heuristics might be used to detect SCONE-compatible
   QUIC flows.  This includes identification of a QUIC handshake on the
   flow, the presence of indications (Section 6.1), or other heuristics.
   If these heuristics indicate a non-QUIC flow, the safest option is
   for network elements to disable updating of datagrams.

10.  Privacy Considerations

   The focus of this analysis is the extent to which observing SCONE
   packets could be used to gain information about endpoints.  This
   might be leaking details of how applications using QUIC operate or
   leaks of endpoint identity when using additional privacy protection,
   such as a VPN.

   Any network element that can observe the content of that packet can
   read the throughput advice that was applied.  Any signal is visible
   on the path, from the point at which it is applied to the point at
   which it is consumed at an endpoint.  On path elements can also alter
   the SCONE signal to try trigger specific reactions and gain further
   knowledge.

   In the general case of a client connected to a server through the
   Internet, SCONE does not provide much advantage to attackers.  The
   identities of the clients and servers are already visible through
   their IP addresses.  Traffic analysis tools already provide more
   information than the throughput advice set by SCONE.

   There are two avenues of attack that require more analysis:

   *  that the passive observation of SCONE packets might help identify
      or distinguish endpoints; and

Thomson, et al.           Expires 13 March 2027                [Page 24]
Internet-Draft               SCONE Protocol               September 2026

   *  that active manipulation of SCONE signals might help reveal the
      identity of endpoints that are otherwise hidden behind VPNs or
      proxies.

10.1.  Passive Attacks

   If only a few clients and server pairs negotiate the usage of SCONE,
   the occasional observation of SCONE packets will "stick out".  That
   observation could be combined with observation of timing and volume
   of traffic to help identify the endpoint or categorize the
   application that they are using.

   A variation of this issue occurs if SCONE is widely implemented, but
   only used in some specific circumstances.  In that case, observation
   of SCONE packets reveals information about the state of the endpoint.

   If multiple servers are accessed through the same front facing
   server, Encrypted Client Hello (ECH) can prevent outside parties from
   identifying which specific server a client is using.  However, if
   only a few of these servers use SCONE, any SCONE packets will help
   identify which specific server a client is using.

   This issue will be mitigated if SCONE becomes widely implemented, and
   if the usage of SCONE is not limited to the type of applications that
   make active use of the signal.

   QUIC implementations are therefore encouraged to make the feature
   available unconditionally.  Endpoints might send SCONE packets
   whenever a peer can accept them.

10.2.  Active Attacks

   Suppose a configuration in which multiple clients use a VPN or proxy
   service to access the same server.  The attacker sees the IP
   addresses in the packets behind VPN and proxy and also between the
   users and the VPN, but it does not know which VPN address corresponds
   to what user address.

   Suppose now that the attacker selects a flow on the link between the
   VPN/proxy and server.  The attacker applies throughput advice to
   SCONE packets in that flow.  The attacker chooses a bandwidth that is
   lower than the "natural" bandwidth of the connection.  A reduction in
   the rate of flows between client and VPN/proxy might allow the
   attacker to link the altered flow to the client.

Thomson, et al.           Expires 13 March 2027                [Page 25]
Internet-Draft               SCONE Protocol               September 2026

   +--------+
   | Client |------.
   +--------+       \      +-------+
                     '---->|       |            +--------+
   +--------+              |  VPN  |<==========>|        |
   | Client |------------->|   /   |<==========>| Server |
   +--------+              | Proxy |<==========>|        |
                     .---->|       |     ^      +--------+
   +--------+       /      +-------+     |
   | Client |======'                     |
   +--------+      ^           Apply throughput advice signal
                    \
                     \
                  Observe change

           Figure 3: Client identification attack on VPN or proxy

   An attacker that can manipulate SCONE headers might cause an
   observable change in sending behavior; see Figure 3.  Though clients
   that use a VPN or proxy might choose to disable SCONE, removing SCONE
   signals is of little help against this form of attack.  Lost or ECN-
   marked packets are likely to produce a congestion control response,
   which are alternative methods available to an attacker seeking to
   match flows.

   An effective, but wasteful, defense is to provide cover traffic
   between the client and intermediary to mask changes in sending rate
   on tunneled flows.

11.  IANA Considerations

   This document registers new QUIC versions (Section 11.1) and a QUIC
   transport parameter (Section 11.2).

11.1.  SCONE Versions

   This document registers the following entries to the "QUIC Versions"
   registry maintained at https://www.iana.org/assignments/quic
   (https://www.iana.org/assignments/quic), following the guidance from
   Section 22.2 of [QUIC].

   Value:  0x6f7dc0fd
   Status:  permanent
   Specification:  This document
   Change Controller:  IETF (iesg@ietf.org)
   Contact:  QUIC Working Group (quic@ietf.org)
   Notes:  SCONE Protocol - Even Signal Values

Thomson, et al.           Expires 13 March 2027                [Page 26]
Internet-Draft               SCONE Protocol               September 2026

   Value:  0xef7dc0fd
   Status:  permanent
   Specification:  This document
   Change Controller:  IETF (iesg@ietf.org)
   Contact:  QUIC Working Group (quic@ietf.org)
   Notes:  SCONE Protocol - Odd Signal Values

11.2.  scone_supported Transport Parameter

   This document registers the scone_supported transport parameter in
   the "QUIC Transport Parameters" registry maintained at
   https://www.iana.org/assignments/quic
   (https://www.iana.org/assignments/quic), following the guidance from
   Section 22.3 of [QUIC].

   Value:  0x219e
   Parameter Name:  scone_supported
   Status:  Permanent
   Specification:  This document
   Date:  This date
   Change Controller:  IETF (iesg@ietf.org)
   Contact:  QUIC Working Group (quic@ietf.org)
   Notes:  (none)

12.  References

12.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

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

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

   [INVARIANTS]
              Thomson, M., "Version-Independent Properties of QUIC",
              RFC 8999, DOI 10.17487/RFC8999, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8999>.

Thomson, et al.           Expires 13 March 2027                [Page 27]
Internet-Draft               SCONE Protocol               September 2026

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [QUIC-BIT] Thomson, M., "Greasing the QUIC Bit", RFC 9287,
              DOI 10.17487/RFC9287, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9287>.

   [QUICv2]   Duke, M., "QUIC Version 2", RFC 9369,
              DOI 10.17487/RFC9369, May 2023,
              <https://www.rfc-editor.org/rfc/rfc9369>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/rfc/rfc2474>.

12.2.  Informative References

   [CONNECT-UDP]
              Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
              DOI 10.17487/RFC9298, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9298>.

   [DASH]     "Information technology — Dynamic adaptive streaming over
              HTTP (DASH) — Part 1: Media presentation description and
              segment formats", ISO/IEC 23009-1:2022, August 2022,
              <https://www.iso.org/standard/83314.html>.

   [ECN]      Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/rfc/rfc3168>.

   [HLS]      Pantos, R., Ed. and W. May, "HTTP Live Streaming",
              RFC 8216, DOI 10.17487/RFC8216, August 2017,
              <https://www.rfc-editor.org/rfc/rfc8216>.

   [QUIC-MP]  Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema,
              C., and M. Kühlewind, "Managing multiple paths for a QUIC
              connection", Work in Progress, Internet-Draft, draft-ietf-
              quic-multipath-21, 17 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              multipath-21>.

Thomson, et al.           Expires 13 March 2027                [Page 28]
Internet-Draft               SCONE Protocol               September 2026

   [RFC1141]  Mallory, T. and A. Kullberg, "Incremental updating of the
              Internet checksum", RFC 1141, DOI 10.17487/RFC1141,
              January 1990, <https://www.rfc-editor.org/rfc/rfc1141>.

   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
              2007, <https://www.rfc-editor.org/rfc/rfc4787>.

   [SCONE-MAN]
              Mishra, S., Sarker, Z., Tomar, A., and K. Abbas,
              "Applicability & Manageability Considerations for SCONE",
              Work in Progress, Internet-Draft, draft-ietf-scone-
              applicability-manageability-02, 20 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-scone-
              applicability-manageability-02>.

   [WHY-ECN]  Fairhurst, G. and M. Welzl, "The Benefits of Using
              Explicit Congestion Notification (ECN)", RFC 8087,
              DOI 10.17487/RFC8087, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8087>.

Acknowledgments

   Jana Iyengar made significant contributions to the original TRAIN
   specification that forms the basis for a large part of this document.
   The following people also contributed significantly to the
   development of the protocol: Alan Frindell, Gorry Fairhurst, Kevin
   Smith, Martin Duke, and Zaheduzzaman Sarker.

Authors' Addresses

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net

   Christian Huitema
   Private Octopus Inc.
   Email: huitema@huitema.net

   Kazuho Oku
   Fastly
   Email: kazuhooku@gmail.com

   Additional contact information:

Thomson, et al.           Expires 13 March 2027                [Page 29]
Internet-Draft               SCONE Protocol               September 2026

      奥 一穂
      Fastly

   Matt Joras
   Meta
   Email: matt.joras@gmail.com

   Marcus Ihlar
   Ericsson
   Email: marcus.ihlar@ericsson.com

Thomson, et al.           Expires 13 March 2027                [Page 30]