SCONE S. Gundavelli Internet-Draft Ameriband Intended status: Informational M. Grayson Expires: 6 May 2027 Cisco Systems J. Redmore CableLabs J. Padden Nova Labs 2 November 2026 SCONE Applicability for IEEE 802.11 Access Networks draft-gundavelli-scone-wifi-applicability-01 Abstract This document describes the applicability of the Standard Communication with Network Elements (SCONE) protocol to IEEE 802.11 based access networks. SCONE defines a mechanism by which an on-path network element can provide advisory downlink throughput guidance to QUIC endpoints. The SCONE protocol is access agnostic and does not assume any specific access technology. In IEEE 802.11 deployments, such constraints may be derived at access points or controllers that combine policy awareness, with visibility into access network conditions. This document explains how existing SCONE roles and throughput advice semantics apply in these deployments without assuming any specific IEEE 802.11 MAC or PHY behavior. This document does not define new protocol extensions and does not modify SCONE behavior. Its purpose is to clarify deployment considerations for IEEE 802.11 environments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Gundavelli, et al. Expires 6 May 2027 [Page 1] Internet-Draft SCONE-802.11 Applicability November 2026 This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. IEEE 802.11 Deployment Models and Policy Considerations . . . 4 2.1. Distributed Access Point Deployment . . . . . . . . . . . 4 2.2. Centralized Controller-Based Deployment . . . . . . . . . 5 2.3. Cloud-Managed Deployment . . . . . . . . . . . . . . . . 5 2.4. Policy Based Throughput Constraints . . . . . . . . . . . 6 3. IEEE 802.11 Specific Implementation Considerations . . . . . 7 3.1. Inter Access Point Handovers . . . . . . . . . . . . . . 8 4. Wi-Fi Throughput Rate Estimation . . . . . . . . . . . . . . 8 4.1. Inputs Available at the AP / WLC . . . . . . . . . . . . 8 4.1.1. Link Quality . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Loss and Retransmission . . . . . . . . . . . . . . . 9 4.1.3. Queues and Buffers . . . . . . . . . . . . . . . . . 9 4.1.4. Channel Load and STA Activity . . . . . . . . . . . . 9 4.1.5. Backhaul and Policy . . . . . . . . . . . . . . . . . 10 4.2. Downlink and Uplink . . . . . . . . . . . . . . . . . . . 10 4.3. Combining the Inputs . . . . . . . . . . . . . . . . . . 10 4.4. Placement of the Estimate . . . . . . . . . . . . . . . . 11 4.5. Expected Behavior of the Inputs . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Gundavelli, et al. Expires 6 May 2027 [Page 2] Internet-Draft SCONE-802.11 Applicability November 2026 1. Introduction SCONE [I-D.ietf-scone-protocol] provides a mechanism for on-path network elements to convey advisory uplink throughput guidance to QUIC [RFC9000] endpoints. The guidance reflects throughput constraints that apply along the network path. SCONE is access agnostic and does not assume any specific access technology. IEEE 802.11 [IEEE80211-2024] access networks are widely deployed across enterprise, residential, and public hotspots. In these networks, throughput constraints may arise from administrative policy or service differentiation and may be applied at different points in the access network, including access points, wireless controllers, or gateways. These characteristics motivate an applicability discussion for IEEE 802.11, without altering the access-agnostic design of SCONE. In enterprise IEEE 802.11 deployments, throughput constraints are commonly derived from subscriber, device, or service policy conveyed through Authentication, Authorization, and Accounting (AAA) systems over RADIUS protocol ([RFC2865]). Access points or controllers enforce such policies as part of the session management function in the access network. SCONE can be used in these environments to expose the resulting throughput guidance to QUIC endpoints, without assuming or relying on IEEE 802.11 MAC or PHY behavior. This document does not require any particular estimation technique. When SCONE is used in an IEEE 802.11 deployment, the SCONE Network Element exposes advisory throughput guidance that reflects the outcome of air interface and policy conditions. Section 4 describes access-local inputs that can influence that estimate. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology All the terms used in this document are to be interpreted as defined in the IETF SCONE [I-D.ietf-scone-protocol], QUIC [RFC9000] and IEEE 802.11 [IEEE80211-2024] specifications. For convenience, the definitions for some of the terms are provided below. STA (Station) - IEEE 802.11 Station Gundavelli, et al. Expires 6 May 2027 [Page 3] Internet-Draft SCONE-802.11 Applicability November 2026 AP (Access Point) - IEEE 802.11 Access Point AAA - Authentication, Authorization and Accounting 2. IEEE 802.11 Deployment Models and Policy Considerations IEEE 802.11 access networks are commonly deployed based on two dominant architectural models, distinguished by whether control and policy functions are distributed at the access point or centralized in a controller. While implementations vary, most deployments follow one of these two approaches. In addition, many deployments use cloud-managed systems to host configuration, monitoring, and policy distribution functions outside the local network. These management systems typically do not participate directly in data forwarding. In all deployment models, AAA systems are commonly used to host network credentials and policy elements that influence access and service treatment. These systems provide a consistent source of policy configuration, regardless of whether enforcement is applied locally at the access point, centrally at a controller, or based on configuration distributed through cloud-managed systems. In smaller or less complex deployments, policy and credential information is configured locally on the access point or controller without the use of an external AAA system. The following subsections describe these deployment models and identify where SCONE network element functionality may reside. 2.1. Distributed Access Point Deployment In the distributed access point deployment model, the IEEE 802.11 Access Point (AP) performs radio termination, policy enforcement, and local data forwarding, without a centralized controller in the data path. This model is commonly used in residential networks, small enterprises, and branch deployments. Authentication and authorization are performed during association using standard IEEE 802.11 mechanisms. Policy information may be conveyed to the AP through a AAA system over RADIUS protocol, or configured locally in these deployments. Based on these interfaces, the AP applies policy for the associated station. Throughput constraints in this model are enforced directly at the AP. When such constraints are applied, the AP functions as an on-path network element capable of exposing advisory throughput guidance using SCONE for flows traversing the access network. Gundavelli, et al. Expires 6 May 2027 [Page 4] Internet-Draft SCONE-802.11 Applicability November 2026 AAA | | (Policy / Credentials) | STA -- AP with SCONE NE -- [IP Network] Figure 1: Distributed Access Point Deployment with SCONE Network Element 2.2. Centralized Controller-Based Deployment In the centralized controller-based deployment model, the Access Points operate under the control of a wireless controller that performs centralized coordination and policy control across multiple APs. Data forwarding may be centralized at the controller or distributed at the APs, depending on deployment design, while policy decisions are typically made centrally. Authentication and authorization are commonly handled through centralized interaction with AAA system. Policy information obtained during authorization is applied consistently across APs serving the associated station. This model is widely used in enterprise and campus environments where centralized policy control and mobility management are required. Throughput constraints in this model may be enforced either at the controller or at the access points under controller direction. The SCONE network element function resides at the point in the data path where such constraints are applied. In deployments where enforcement remains local to the access point, SCONE placement is similar to the distributed access point model described in Section 2.1. AAA | | (Policy / Credentials) | STA -- AP -- [Controller with SCONE NE] -- [IP Network] Figure 2: Centralized Controller-Based Deployment with SCONE Network Element 2.3. Cloud-Managed Deployment In cloud-managed deployments, the Access Points are configured and monitored using a remote management system hosted outside the local access network. These systems provide centralized configuration and monitoring functions, while data forwarding remains within the local network. The cloud management system does not participate in data forwarding or SCONE signaling. However, it can interwork with the SCONE NE on rate guidance estimates. Gundavelli, et al. Expires 6 May 2027 [Page 5] Internet-Draft SCONE-802.11 Applicability November 2026 Authentication and authorization are commonly performed using AAA systems, with policy information conveyed either directly to the access points or through configuration distributed by the cloud management system. In smaller deployments, equivalent policy information may be configured locally. Throughput constraints in this model are enforced locally at the access point. When such constraints are applied, the access point represents the on-path network element capable of exposing advisory throughput guidance using SCONE. _----_ _( Cloud)_ ( Mgmt ) (_ _) '----' | | | STA -- [AP with SCONE NE] -- [IP Network] | | (Policy / Credentials) AAA Figure 3: Cloud-Managed Deployment and SCONE Placement 2.4. Policy Based Throughput Constraints Many enterprise and service-provider Wi-Fi deployments rely on AAA infrastructure for policy and authentication, commonly using RADIUS. During authentication, the access point or controller acts as an AAA client and may receive authorization attributes that override locally configured WLAN policy. AAA-based policy mechanisms are commonly used to convey per-user parameters such as maximum uplink and downlink throughput, traffic shaping or policing profiles, session duration limits, or QoS classification. These parameters reflect administrative or subscription-based policy and are enforced by the access point or controller. While no standardized AAA attribute defines per-user Wi-Fi throughput, vendor-specific attributes are widely deployed to convey bandwidth limits or rate profiles. Despite differences in representation, these attributes share a common semantic meaning: a bounded, policy-defined sustainable throughput for a user session. Gundavelli, et al. Expires 6 May 2027 [Page 6] Internet-Draft SCONE-802.11 Applicability November 2026 When such policy-based throughput constraints are enforced in the data path, SCONE signaling may be used to expose corresponding advisory throughput guidance to endpoints. SCONE reflects the outcome of applied policy without exposing AAA attributes, policy rules, or authentication state. 3. IEEE 802.11 Specific Implementation Considerations In IEEE 802.11 deployments, the access point is the enforcement point for access policy and traffic treatment. As part of normal operation, the access point has continuous visibility into activity within its Basic Service Set (BSS), covering both uplink and downlink transmissions for associated stations. This visibility is intrinsic to IEEE 802.11 operation and is independent of higher-layer protocols. The access point maintains access-local operational context related to the shared wireless medium and connected stations. This context may include, but is not limited to: * PHY Rate (MCS Index) * Channel Load * Queue Backlog (Buffer Status) * Packet Error Rate (PER) / Retries * Station Signal Strength (SNR/RSSI) * Active Contending Stations Such information is maintained to support normal access network operation and enforcement and does not require any SCONE-specific functionality. In practice, access points may use this access-local context, together with subscription-based policy, to determine throughput constraints that can be sustainably enforced. These determinations may vary over time due to changes in the active station set, mobility, interference, or traffic patterns. This document does not mandate a specific rate-estimation algorithm or require the use of any particular IEEE 802.11 parameter. When SCONE is used in an IEEE 802.11 deployment, the SCONE Network Element exposes advisory throughput guidance that reflects air-interface and policy conditions. Section 4 provides informative guidance on access-local inputs that can influence that estimate. Gundavelli, et al. Expires 6 May 2027 [Page 7] Internet-Draft SCONE-802.11 Applicability November 2026 3.1. Inter Access Point Handovers In IEEE 802.11 deployments, stations may move between access points due to mobility, radio conditions, or load management. When a station transitions to a new access point, the data path for active flows also moves. Since SCONE throughput guidance reflects locally enforced constraints and is carried in-band, continuity of guidance across access point transitions is desirable to avoid extended gaps in updates. Each access point independently observes its local radio and network conditions and can generate SCONE throughput guidance based on locally applied policy and enforcement. After a transition, the new access point can generate updated guidance that reflects its own conditions. In many deployments, a limited amount of per-station context is transferred between access points or coordinated through a controller during mobility events. This context may include policy or enforcement-related information. Where such context is available, it may be used by the new access point to initialize SCONE-related state for ongoing sessions and reduce delay before updated guidance is provided. This document does not require access points to exchange per-flow SCONE timers or define any specific state transfer mechanism. SCONE guidance remains advisory, and endpoints are expected to tolerate brief changes or gaps in guidance following mobility events. The generation and update of SCONE throughput guidance after a transition remains a local decision at the new access point. 4. Wi-Fi Throughput Rate Estimation The SCONE protocol [I-D.ietf-scone-protocol] defines how an on-path network element can provide throughput advice. It does not define how that rate is calculated. This section describes input factors that an IEEE 802.11 Access Point or Wireless LAN Controller can use when forming such an estimate for downlink and uplink. This section is informative. It does not define an algorithm or require any specific IEEE 802.11 parameter. Throughput advice applies to the path direction of the SCONE packets that carry it [I-D.ietf-scone-protocol]. 4.1. Inputs Available at the AP / WLC An AP already maintains radio and traffic state for normal BSS operation. A WLC may obtain the same class of information from connected APs. The lists below are examples of inputs that can affect a rate estimate. Not every deployment exposes every input. Gundavelli, et al. Expires 6 May 2027 [Page 8] Internet-Draft SCONE-802.11 Applicability November 2026 4.1.1. Link Quality * Current PHY / MCS rate used by the AP when transmitting to that STA (downlink), or used by that STA when transmitting to the AP as observed at the AP (uplink) * SNR or RSSI for that STA * Operating channel width and number of spatial streams * PHY mode in use (for example, 802.11ac, 802.11ax, or 802.11be) The PHY / MCS rate is a starting point only. Usable throughput is usually lower after overhead, loss, and sharing of the medium. Downlink and uplink MCS for the same STA can differ. 4.1.2. Loss and Retransmission * Retry count, packet error ratio, or Block Ack failure rate in the estimated direction * Other local indicators of contention or repeated failure on the channel Failed deliveries use airtime without advancing useful payload. Higher loss or retry activity in a direction therefore usually supports a lower sustainable rate than the nominal PHY / MCS rate in that direction. Uplink loss can differ from downlink loss for the same STA. 4.1.3. Queues and Buffers * Downlink: AP transmit queue depth for the STA, or for the access category used by that traffic; overall AP buffer load if used by the implementation * Uplink: Buffer Status Report (BSR) or other uplink queue information, when reported by the STA Sustained queue growth indicates that offered traffic is above what is being cleared. Implementations may lower the estimated rate when queues for that STA or direction remain high. Uplink queue state, when known, is per STA. 4.1.4. Channel Load and STA Activity * Channel busy fraction / BSS load / CCA statistics Gundavelli, et al. Expires 6 May 2027 [Page 9] Internet-Draft SCONE-802.11 Applicability November 2026 * Interference from neighboring BSSs, when the AP distinguishes it * Number of associated STAs and number of STAs recently active * Recent throughput per STA in the estimated direction These inputs affect how much transmit opportunity is available and how it is divided among STAs. The division depends on the AP's scheduler (for example, EDCA, airtime fairness, or OFDMA resource unit scheduling). With more busy time or more active STAs, the per- STA rate estimate is often lower for the same link quality. 4.1.5. Backhaul and Policy * Capacity and load of the AP's wired / backhaul uplink * Per-STA or per-subscription rate limits already applied by the AP or WLC (including limits learned from AAA) If the wired uplink is the bottleneck, the radio-derived rate is not the limiting factor. If a policy rate limit is already enforced for the STA, the advice can reflect that limit. SCONE carries the resulting rate value; it does not carry AAA attributes. 4.2. Downlink and Uplink Downlink estimates commonly use AP transmit MCS, downlink retries, AP transmit queues, and downlink scheduling state for that STA. Uplink estimates are more dependent on per-STA state: uplink MCS as seen at the AP, uplink retries, and uplink buffer indications when available. Shared channel load still applies. On 802.11ax and later, scheduled uplink OFDMA, when used, also affects how uplink airtime is granted to each STA. Downlink and uplink estimates are separate. Backhaul and policy limits may apply to one direction, both, or neither, depending on how the network is configured. 4.3. Combining the Inputs Different products will combine these inputs in different ways. In general, a rate estimate accounts for: * link rate after loss and overhead in that direction; * sharing of the wireless medium among active STAs; Gundavelli, et al. Expires 6 May 2027 [Page 10] Internet-Draft SCONE-802.11 Applicability November 2026 * queue buildup at the AP (downlink) or STA (uplink), when used; * available backhaul capacity; and * any rate policy already enforced for the STA. The advice given to SCONE is a single rate for that direction. How the inputs are weighted, filtered, or updated over time is a local implementation choice. An implementation may use an existing scheduler or shaping result instead of computing a separate model. SCONE itself carries only the rate signal [I-D.ietf-scone-protocol]. Congestion control at the endpoints remains in effect. Endpoints may ignore the advice. 4.4. Placement of the Estimate * On a distributed AP, the estimate is typically computed on the AP, which also has the radio counters and, when it is on-path, can update SCONE packets. * With a WLC, policy and some STA context may be centralized. The rate may be computed at the WLC if the WLC receives sufficient telemetry and can update the packets on path. Otherwise the AP computes and applies the rate, possibly using policy distributed by the WLC. * In cloud-managed networks, configuration and policy may come from the cloud, but the on-path SCONE update is still performed by an on-path device (usually the AP). 4.5. Expected Behavior of the Inputs If the inputs above are used, the following qualitative behavior is expected: * Higher loss or retries, with MCS unchanged, tend to lower the estimate. * Growing AP transmit queues (downlink) or reported STA uplink queues tend to lower the estimate. * Higher channel busy time or more active STAs tend to lower the per-STA estimate. * An enforced policy rate cap limits the estimate to that cap. Gundavelli, et al. Expires 6 May 2027 [Page 11] Internet-Draft SCONE-802.11 Applicability November 2026 * A constrained backhaul link can limit the estimate even when the radio link is strong. Uplink results should be interpreted per STA. Uplink MCS, loss, and buffer state are not the same for all STAs on a BSS. 5. IANA Considerations This document does not define any new protocol mechanisms, or require any registry updates. Therefore, it does not require any IANA actions. 6. Security Considerations This document does not define new protocol mechanisms and does not introduce new threats beyond those described in the SCONE protocol specification. SCONE capability is negotiated end to end between QUIC endpoints using SCONE protocol elements. After negotiation, throughput advice values carried in SCONE packets may be inserted, updated, or removed by on path network elements. The throughput advice value is not authenticated, and endpoints cannot guarantee that a received value was inserted by a particular on-path network element. In IEEE 802.11 deployments, throughput constraints may reflect policy-based configuration, including policies informed by Authentication, Authorization, and Accounting (AAA) systems over RADIUS protocol . This document does not require exposure of AAA attributes, authentication state, or other sensitive policy information to endpoints explicitly. Exposing throughput constraints through SCONE to an endpoint can reveal limited information about network policy or service differentiation through inference. This disclosure risk is inherent to SCONE signaling and is not specific to IEEE 802.11 deployments. Operators should consider the granularity and update frequency of throughput advice to limit unnecessary exposure. Endpoints are free to ignore advice they consider incorrect or inappropriate. 7. Acknowledgements Thanks to Marting Thompson for reviewing this document and providing some review feedback. Also, thanks to the discussions in Wireless Broadband Alliance on the use of SCONE for Wi-Fi environments. 8. References Gundavelli, et al. Expires 6 May 2027 [Page 12] Internet-Draft SCONE-802.11 Applicability November 2026 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-scone-protocol] Thomson, M., Huitema, C., Oku, K., Joras, M., and L. M. Ihlar, "Standard Communication with Network Elements (SCONE) Protocol", Work in Progress, Internet-Draft, draft-ietf-scone-protocol-10, 28 October 2026, . 8.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [IEEE80211-2024] IEEE, "IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2024, 28 April 2025, . Authors' Addresses Sri Gundavelli Ameriband CA 95135 United States of America Email: sri.ietf@gmail.com Gundavelli, et al. Expires 6 May 2027 [Page 13] Internet-Draft SCONE-802.11 Applicability November 2026 Mark Grayson Cisco Systems 10 New Square Park Feltham TW14 8HA United Kingdom Email: mgrayson@cisco.com Joshua Redmore CableLabs 858 Coal Creek Cr. Louisville, 80027 United States of America Email: j.redmore@cablelabs.com Joey Padden Nova Labs Boulder, Colorado United States of America Email: jpadden@nova-labs.com Gundavelli, et al. Expires 6 May 2027 [Page 14]