Session Date/Time: 21 May 2025 21:00

SCONE

Summary

The SCONE working group held its third interim meeting, primarily focusing on an issue scrub and discussion of Pull Requests (PRs) related to the joint protocol proposal. The call for adoption for this proposal concludes at the end of the week (24th), with strong support expected. A significant portion of the meeting was dedicated to the ongoing discussion around early indications in SCONE flows, their impact on network operator incentives, potential privacy concerns, and overall protocol adoption.

Key Discussion Points

Joint Protocol Proposal Adoption Call: The open call for adoption for the joint protocol proposal is expected to conclude on the 24th, with no indications of opposition. The authors are anticipated to be asked to submit an IETF 0000 revision of the document next week.
PR31: Renaming "Rate Limits" to "Throughput Advice":
- This PR aims to align terminology more closely with the charter and clarify that the scope is broader than just network throttling.
- The change was deemed largely uncontroversial.
- Martin confirmed that requested changes were made and he was satisfied.
- Decision: PR31 is considered mergeable.
Issue #5 / PR23: Early Indications in SCONE Flows: This was the primary discussion point, stemming from a previous PR and evolving into a broader issue.
- Background (Marcus's Summary): The idea originated from a need for early detection of SCONE-capable flows to help network elements identify and apply policies (e.g., rate limiting) without relying on deep packet inspection (DPI). This could incentivize operators to adopt SCONE by reducing their DPI burden.
- Concerns Raised:
  - Scalability/Utility: The usefulness of early indications might diminish as SCONE adoption becomes widespread across various applications, not just video.
  - "Throttle Me" Signal: A worry that using SCONE for early identification could lead to it being perceived as a "throttle me" signal, discouraging adoption by other applications or browsers.
  - Privacy/Fingerprinting: Concerns were raised that an explicit early indication could become a new vector for fingerprinting application types, even if DPI is reduced. Christian argued against creating signals that enable new forms of fingerprinting.
  - Charter Scope: Questions were raised about whether defining a signal to indicate traffic type or drive policy decisions is within the SCONE working group's charter, which focuses on providing throughput information from network to client.
- Arguments in Favor/Clarifications:
  - Incentive for Deployment: Several participants emphasized that the early indication serves as a pragmatic incentive for network operators to deploy SCONE, particularly for policies currently driven by costly DPI (e.g., video traffic classification). Matt argued that the indication provides no new information not already available via other means (e.g., SNI in Client Hello), but makes it easier for operators to apply existing policies without DPI.
  - SCONE vs. Congestion Control: Clarified that SCONE is not intended to solve congestion control problems, but rather to inform adaptive bitrate applications about network-preferred throughput.
  - Chair's Perspective (Brian): The working group is chartered for cooperative signaling. While not explicitly chartered to define a new signal just for policy, Hyram's Law dictates that the existence of SCONE will be used for inference. The core question for the WG is whether an early indication is a useful way to drive early adoption.
  - Endpoint Behavior: Martin noted that if browsers (e.g., Firefox) decide to advertise SCONE capability on every Quick flow, many of the current debates (DPI relief, fingerprinting concerns) become less operative, as the signal would no longer distinguish traffic types. Matt countered that even with universal adoption, a transition period would still benefit from early indications for network deployment.
- Architectural Implications: Christian highlighted multipath scenarios where DPI on the initial path would be irrelevant on subsequent paths, arguing for a model where the network "benevolently" reflects its decisions in SCONE packets without requiring early indications. Marcus disagreed, stating SCONE also allows clients to request viable rates even without active throttling. Ian stressed that multipath/net-rebinding is not an edge case and impacts traffic identification.
- Straw Man Proposal: A straw man proposal for an early indication mechanism exists and is linked within Issue #5, intended to guide discussion on implementation.

Decisions and Action Items

PR31 (Rename Rate Limits): To be merged.
Joint Protocol Proposal Adoption: The call for adoption is expected to be successful by next week (ending 24th). Authors are requested to prepare an IETF 0000 revision of the document once adopted.
Issue #5 (Early Indications): Discussion will continue on the GitHub thread. Participants are encouraged to focus on:
- Whether an early indication of SCONE capability is useful for driving early adoption, and why or why not.
- Properties of its implementation that would make it more or less useful for this purpose.
- Sub-discussions that arose from this topic (e.g., specific philosophical points) should be carved off into separate issues if they warrant further dedicated exploration.
HedgeDoc Notes: The notes from this discussion will be published as official meeting minutes and will inform the ongoing discussion on Issue #5.

Next Steps

The chairs will finalize the call for adoption of the joint protocol proposal next week.
The community is requested to engage actively in the GitHub discussion for Issue #5, leveraging the insights from this meeting to work towards convergence.
Consideration will be given to multipath issues and their implications for SCONE, potentially leading to new issues or specific language in the document.