**Session Date/Time:** 07 Nov 2024 09:30

# scone

## Summary
The first working group meeting for SCONE focused on establishing the group's goals, reviewing existing protocol proposals (NRLP, Mask-based, and Scone Train), and determining next steps towards standardization. A key point of discussion was defining the scope of the working group's efforts, specifically the interpretation of "limiters" and "limits" within the network. The group decided on a two-track approach moving forward, one focused on the format/syntax of data being exchanged and another focused on the content/semantics.

## Key Discussion Points
*   **Charter Scope:** Extensive debate arose regarding the scope of the charter, particularly concerning the definition of "limiters" (active devices enforcing rate limits) versus "limits" (inherent path limitations).  The applicability of the solutions to scenarios with or without active traffic shaping was discussed.
*   **Endpoint Definition:** Clarification was sought on the definition of "endpoint," considering scenarios involving MAS proxies and tunnels. The question of whether the endpoint refers to the congestion controller or the ultimate sender was raised.
*   **Protocol Proposals:**
    *   **NRLP:** Matt presented NRLP, emphasizing its deployability and alignment with existing network practices. Key features include trust-based security, fairness to applications, transport protocol independence, and immunity against UDP flow table changes.
    *   **Mask-based:** Marcus presented a proposal using MAS proxies for throughput advice, focusing on integrating with existing MAS connections and a simple wire format.
    *   **Scone Train:** Martin presented Scone Train, attaching signals to flows and using a special quick version for packet marking. Security and privacy implications were highlighted.
    *   **Scone Quick Protocol:** Matt presented Scone Quick Protocol, sending specialized packets that resemble quick initials, potentially easier to be implemented into existing practices.
*   **Throughput Advice Content:** Discussions centered on the specific information to be included in throughput advice, such as averaging windows, burst rates, and the overall profile of the throughput.
*   **Bi-directional Throughput Advice:** Ian expressed the need for bi-directional throughput advice, raising questions about whether a single or two separate mechanisms were needed.
*    **Multiple Network Elements**: The question of which signal takes precedence in case of multiple network elements providing advice was discussed.
*   **Multi-path and Connection Migration:** The need for solutions that accommodate multi-path and connection migration, especially regarding ephemeral ports, was emphasized.
*   **Design Team vs. Work Streams:** Debate ensued regarding the best approach for advancing the work, with opinions ranging from forming a design team to pursuing parallel work streams within the working group. Ultimately the community decided to take a two-track approach.
* **Use Cases**: Several participants mentioned the need to better define use cases in order to create useful and effective proposals.

## Decisions and Action Items
*   **Two Work Streams:**  The group agreed to proceed with two parallel work streams:
    *   One focused on the syntax and framing of the protocol.
    *   The other focused on the content and semantics of throughput advice.
*   **Utilize IETF IWG SCONE Repo:** All documents should be merged into the IETF IWG SCONE Repo.
*   **Address Deployability and Security**: The group agreed to incorporate deployment considerations and security concerns into the protocol design from the very beginning.
*   **Propose a Design Team**: Although two tracks were decided, the chair plans to take further suggestion of creating a design team to the mailing list, with the expectation that multiple people can offer their input.

## Next Steps
*   **Schedule Virtual Interim Meetings:** The chairs will schedule three virtual interim meetings between now and the Bangkok IETF meeting. The first meeting will focus on synthesizing the protocol proposals.
*   **Call for volunteers**: The chairs plan to create a request to sign up for the two-track effort over the mailing list, in order to determine who will be in each group.
*   **Implement First**: Group members plan to code up their ideas as quick as possible, in order to have a more concise discussion.
*   **Mailing List Discussions:** Continued discussions on the mailing list are crucial for defining use cases, clarifying protocol requirements, and converging on a standardized approach.