**Session Date/Time:** 15 Oct 2025 21:00

# [SCONE](../wg/scone.html)

## Summary

The SCONE working group held its third interim meeting since Madrid. The primary focus of the meeting was the planning for the IETF 124 Hackathon, discussing interoperability goals and logistical considerations. Additionally, the group reviewed the latest updates to the applicability and manageability draft (version 02), specifically addressing concerns around scope, normative language, and 3GPP interactions. The discussion on the applicability draft led to a decision to remove normative language and continue discussions on the mailing list. Finally, two open Pull Requests (PRs) related to the base protocol document were reviewed, with one being merged and the other deferred to an issue for further data-driven discussion regarding soft state implementation costs. An existing issue on defining "network element" was also discussed, with a suggestion to convert it into a PR for concrete text.

## Key Discussion Points

*   **IETF 124 Hackathon Planning:**
    *   The hackathon will be free to register for, separate from meeting registration, and allow for both in-person and remote participation.
    *   Participants are encouraged to join the `scone-interop` Slack channel for coordination, especially for remote involvement.
    *   Key technical aspects to test include negotiating transport parameters, receiving client indications at network elements (a newer spec aspect), and the successful propagation and updates of rate indications across the network.
    *   Planning will involve a shared document to coordinate available client, server, and network element implementations.
    *   Remote participants need to consider IP reachability and firewall configurations in advance.
    *   A suggestion was made to use the hackathon time to set up "protocols" for continuous interop testing, potentially leveraging cloud instances and maintaining an interop matrix on the WG wiki and GitHub.
    *   A specific challenge from the previous hackathon was routing traffic through distinct network elements. It was suggested to dedicate time to developing network topologies for this at IETF 124.
    *   The possibility of testing application-side rate regulation based on SCONE advice was raised.

*   **Applicability and Manageability Draft (version 02) Review:**
    *   Version 02 aimed to address feedback, particularly on scope clarification, normative tone, and interactions with 3GPP.
    *   Changes included broadening language beyond mobile networks to cover wireline, Wi-Fi, and enterprise; adding a terminology section; and reducing prescriptive language.
    *   The draft clarified that SCONE operates independently of congestion signals like ECN/L4S, with decisions based on user policy and profile changes.
    *   A significant discussion point was the use of normative language, especially when referring to 3GPP-defined network nodes (e.g., UPF, SMF). Concerns were raised that this could create confusion and interactions with the 3GPP community (SA2).
    *   The distinction between content that belongs in the protocol document (implementation requirements) versus the applicability document (how SCONE functions in a broader context) was highlighted.
    *   The potential need for a liaison statement to 3GPP was discussed, acknowledging active SCONE-related proposals within 3GPP 2SA2.

*   **Open Pull Requests on Base Protocol Document:**
    *   **PR on "Update Throughput Advice Early":** This PR proposed adding guidance for network elements to update throughput advice as early as possible for new flows to better influence application behavior. It also proposed changing "should" to "must" for SCONE packets being the first in a UDP datagram. This was largely uncontroversial.
    *   **PR on "Soft State vs. Set-and-Forget":** This PR initiated a discussion on whether the SCONE protocol should maintain a soft state model (requiring periodic updates even if policy is unchanged) or a set-and-forget model.
        *   Arguments for "set-and-forget" cited concerns about computational cost on network elements (e.g., UPF) when handling a large number of flows, given that policies often don't change frequently.
        *   Arguments for "soft state" suggested that the computational overhead of periodic updates is negligible (e.g., 0.007% of packets for a 5Mbps flow) and that a hard state model would introduce greater complexity and heuristics at endpoints. It was also noted that policies might become more dynamic in future use cases (e.g., mobility between 4G/5G, geographical policies).
        *   There was an acknowledgement that while lab data suggests low impact, production network impact needs further investigation.
        *   A separate, half-formed idea about using a "no change" signal for content providers to acknowledge operating in a constrained capacity was briefly explored.

*   **Open Issue #69: Define Network Element:**
    *   The issue highlighted that the term "network element" is used in the protocol document without a clear definition, leading to varied inferences about its characteristics and functions (e.g., sitting in the access network, visibility to 4-tuples, maintaining state, having rate-limiting policies).
    *   It was suggested that a clear definition is crucial for implementers and that this exercise would uncover underlying assumptions.

## Decisions and Action Items

*   **IETF 124 Hackathon:**
    *   **Decision:** Alan will lead hackathon planning and coordination for SCONE at IETF 124.
    *   **Action Item:** Alan to generate discussion on network element traffic steering in the Slack channel and send a reminder to the mailing list.
    *   **Action Item:** Brian (Chair) to reserve time for a hackathon presentation/readout in the SCONE WG meeting at IETF 124.
    *   **Action Item:** Investigate setting up continuous interop testing mechanisms, potentially leveraging the WG wiki and GitHub for stable test configurations.

*   **Applicability and Manageability Draft:**
    *   **Decision:** The normative language in the applicability and manageability draft will be removed. The authors will revise the draft (e.g., to version 0.3) to reflect this.
    *   **Action Item:** Sanjay to follow up on the mailing list regarding the removal of normative language and point out the upcoming 0.3 version.
    *   **Action Item:** Martin to send a brief note to the mailing list regarding the normative language point.
    *   **Action Item:** The chairs will continue the discussion on the mailing list to converge on these issues before formally considering adoption.
    *   **Action Item:** A liaison statement to 3GPP will be considered and coordinated with active SCONE-related proposals within 3GPP 2SA2.

*   **Open Pull Requests on Base Protocol Document:**
    *   **Decision:** The PR related to updating throughput advice early and mandating SCONE as the first packet in a UDP datagram will be merged.
    *   **Decision:** The PR regarding "Soft State vs. Set-and-Forget" will be closed.
    *   **Action Item:** Alan to open a new issue to capture the concern about the computational expense of the soft state model for network elements, acknowledging the need for further testing and data.

*   **Open Issue #69: Define Network Element:**
    *   **Action Item:** Convert Issue #69 into a Pull Request to provide concrete text for defining "network element" within the protocol document, facilitating direct discussion and refinement. Brian will add a comment to the issue to capture this.

## Next Steps

*   Continue discussions on the mailing list regarding the applicability and manageability draft, aiming for resolution before IETF 124.
*   Hackathon participants to register, join the Slack channel, and start coordinating test plans and network setups.
*   Implementers to explore the performance impacts of the soft state model for SCONE within network elements and share data with the working group.
*   Develop a PR for the definition of "network element" in the base protocol document.
*   Meet at IETF 124 in Montreal.