Session Date/Time: 17 Sep 2025 15:00

SCONE

Summary

The SCONE working group held an interim meeting to discuss the draft-sanjay-scone-applicability-manageability document and review open issues and pull requests for the SCONE protocol.

A significant portion of the meeting focused on the applicability and manageability draft, leading to a decision to initiate a call for working group adoption. Discussions covered the document's scope, its alignment with 3GPP, and various operational considerations.

For the SCONE protocol, Pull Request #61, which addresses the monitoring period and adherence, was extensively reviewed and subsequently merged, with a commitment to address remaining concerns (like "set it and forget it" operation) in a separate issue.

Key Discussion Points

Applicability and Manageability Draft (`draft-sanjay-scone-applicability-manageability`)

Draft History and Scope: Sanjay Kumar presented the latest version (01), outlining its evolution from a use case/requirements document. Initial feedback led to moving requirements to GitHub issues against the core protocol and focusing the draft on applicability and manageability within operator networks.
Document Structure: The draft was restructured to clearly define its scope, focusing on SCONE deployment in 3GPP mobile networks (Section 3) and operational considerations (Section 4). The 3GPP 5G core architecture section was moved to the end for future editing to include 4G.
SCONE in Mobile Networks: Discussion on how SCONE applies to mobile and access networks, which experience variable conditions (congestion, interference, resource allocation). User Plane Function (UPF) or P-Gateway in 4G networks can act as SCONE advisors, interacting with 5G policy functions (PCF, SMF, PCRF).
Operational Considerations:
- Dynamic Updates and Frequency: Discussed the balance between responsiveness to changing conditions and the load on the system. John noted the difference between congestion control (real-time) and data plan throttling (infrequent) on update frequency. Marcus suggested avoiding the term "congestion control" due to its overloaded nature, and highlighted the protocol's evolving rules on update frequency and grace periods. Tangi proposed categorizing updates into random vs. event-triggered.
- "RAT" Terminology: Tangi suggested clarifying the use of "RAT" (Radio Access Technology) to avoid confusion, possibly replacing it with "wireless" or "radio" to make it more accessible to a broader IETF audience. Anup clarified the intent related to technology changes (e.g., 5G to 4G) impacting throughput limits.
- Conformance Monitoring: Marcus raised a concern about the normative language ("must") used for network elements implementing compliance mechanisms, suggesting it should be more of a recommendation or guidance. Anup clarified that monitoring might be done at a network-wide level rather than by individual elements.
- Independence from Congestion Control: The document reiterates that SCONE operates independently of transport-level congestion control algorithms (like ECN or L4S) but acknowledges that operators may use internal congestion control to determine SCONE throughput advice values. Brian emphasized the importance of distinguishing SCONE from ECN/L4S.
- Single SCONE Advisor: Discussion around the proposal that "only one" UPF should send SCONE advice. Tangi pointed out that in PDU sessions, both anchor UPFs and I-UPFs could apply SCONE policy, potentially leading to multiple advisors. Marcus agreed that while network planning might advise against chained nodes sending different advice, different network domains might independently send advice.
- ECN/L4S Harmonization: Tangi and Anup expressed reservations about including discussion on harmonizing SCONE policies with ECN/L4S, preferring to keep them separate. Marcus and Brian suggested that while orthogonal, some policy alignment between these features during network planning is advisable to avoid negative interactions.
Open Issues and Future Work: Included placeholder topics like receiver adaptation, extensibility beyond 4G/5G, update periodicity, and compliance with 3GPP.
Mailing List Feedback: Summarized initial comments from Tina Tsou (general cleanup, more detail on throughput advice generation) and Tangi (document structure, 4G details, potential merging with Tangi's draft).

SCONE Protocol Open Issues (Marcus Ihlar)

Pull Request #61 Review: Marcus presented a summary of PR #61, which consolidates several previous PRs and addresses a number of issues related to monitoring periods, adherence, and update frequency.
- Monitoring Period: Defines a 67-second monitoring period for network elements to assess conformance. The choice of 67 seconds (a prime number) aims to avoid convergence with other system timers.
- Adherence Algorithm: Provides an example algorithm for monitoring adherence, using a sliding window.
- Update Frequency: Explicitly allows for missing updates and recommends sending updates at least twice per monitoring period, potentially more frequently for faster detection of changes or loss.
- Endpoint Behavior: Recommends endpoints follow the lowest throughput advice received in the last monitoring period and to discard state if a lower dynamic update is received to prevent being flagged non-conformant immediately.
- Grace Period: The discussion around the grace period for endpoints to react to lowered throughput advice was punted to a separate issue to avoid blocking the PR merge.
- "Set it and Forget it" vs. Periodic Updates: Alan and Zahed raised a concern about a vendor's interest in a "set it and forget it" operation (no updates unless explicit change) which conflicts with the current PR's requirement for periodic updates (e.g., twice per 67s period). Marcus argued that periodic updates reduce endpoint complexity regarding path changes and unknown state. It was agreed this discussion should be moved to a separate issue to gather more specific motivations if it's a significant architectural blocker.
- Monitoring Period vs. Update Frequency: Anup sought clarification on whether the update frequency is strictly tied to the 67-second period, even if a CSP uses a longer internal monitoring window. Marcus confirmed that the 67-second interval dictates the update frequency to ensure a consistent interval for endpoints.

Decisions and Action Items

Decisions

Applicability and Manageability Draft (draft-sanjay-scone-applicability-manageability): The working group will initiate a 2-week call for adoption for draft-sanjay-scone-applicability-manageability. It was acknowledged that significant work (including structural changes and content additions, e.g., for 4G, and integrating Tangi's feedback/draft) remains, which will be handled as part of the working group process post-adoption.
SCONE Protocol Pull Request #61: Pull Request #61 on the SCONE protocol GitHub repository was approved for merging.

Action Items

WG Chairs:
- Initiate a 2-week call for adoption for draft-sanjay-scone-applicability-manageability to the SCONE mailing list.
- Post-adoption, fork Sanjay Kumar's personal GitHub repository for the applicability and manageability draft into the official SCONE working group GitHub.
- Send a message to the SCONE mailing list to determine who will "eat the time zone pain" for the upcoming interop planning interim in October.
Marcus Ihlar:
- Add a comment to Pull Request #61 to note that the discussion regarding "set it and forget it" operation and related concerns will be addressed in a separate GitHub issue.
- Identify and propose a better term than "congestion control" for future SCONE discussions and documents.
Wes: If not already done, send out information about the SCONE interop channel on the Quick Devs Slack.
SCONE Working Group Participants: Individuals with specific concerns or architectural roadblocks regarding the periodic updates for SCONE (i.e., the "set it and forget it" model) are encouraged to file a crisp GitHub issue outlining their concerns post-merge of PR #61.

Next Steps

The call for adoption for the applicability and manageability draft will conclude in early October.
Upon adoption, the draft will be moved to the SCONE WG GitHub, enabling discussions, issue tracking, and contributions (e.g., adding more 4G details, incorporating feedback from Tangi's draft) via PRs. The aim is to have an IETF 00 version prepared for discussion in Montreal.
An interop planning interim is scheduled for the second or third week of October. Participants interested in interop efforts should join the SCONE interop channel on the Quick Devs Slack.