Could this be used to violate or undermine things like network neutrality protections for network users?

[SpencerDawkins]

Net neutrality comes in many flavors, and has many different definitions. The potential for combinatorial explosion are limitless.

We don't see existing architectural guidance about this from the IETF, the IESG, or the IAB at this point.

[Kevsy]

Net neutrality comes in many flavors, and has many different definitions

....and at least in the EU, many interpretations of those definitions, of which the decisive one is that of the national telecommunications regulator.

Caveat: I have been involved with this topic for some time, but IANAL, so consider this my technical perspective on current regulation.

Guidance to these EU national regulators is provided by the BEREC guidelines, updated 2022 (BEREC = Board of European Regulators for Electronic Communications).

The key clauses related to Net Neutrality ('Open Internet Regulation') are in Article 3 which deal with 'traffic management' by the Internet access provider (e.g. cellular, satellite or fixed ISP). My interpretation of the wording is that traffic management is an action by the network operator to directly affect a flow of traffic within its network. Although that is allowed with certain conditions (ref: Article 3(3) second subparagraph: reasonable traffic management) , I believe that SCONE would not fall under the definition of traffic management since it is a hint rather than an action. I.e., it would not breach Net Neutrality, and could be offered to all content providers (non-discriminatory).

Should the SCONE WG be approved I'd be happy to ask our legal team for their interpretation.

[jlivingood]

We don't see existing architectural guidance about this from the IETF, the IESG, or the IAB at this point.

There are many things the IETF does based on all sorts of requirements and there is a feedback loop from the market (incl regulatory environment) to the standards process. To use one example, the IETF previously held a P2Pi workshop on similar issues, see RFC 5594 - https://www.rfc-editor.org/rfc/rfc5594.html. That workshop - borne from a NN issue - drove the creation of LEDBAT, CDNI, and other WGs over time. It has arguably had influence on new congestion control AQMs and the development of dual queue networking in TSVWG.

So I don't think we can claim the IETF has not, does not, or should not consider these things.

Rather - why not take it on directly, and add a section on the NN rule implications in many markets (EU, UK, US, Canada, etc.)?

[jlivingood]

My interpretation of the wording is that traffic management is an action by the network operator to directly affect a flow of traffic within its network. Although that is allowed with certain conditions (ref: Article 3(3) second subparagraph: reasonable traffic management) , I believe that SCONE would not fall under the definition of traffic management since it is a hint rather than an action. I.e., it would not breach Net Neutrality, and could be offered to all content providers (non-discriminatory).

Seems reasonable. And I think some of the presentations we heard suggest to me that any SCONE hint provided from the network was about not a desired bitrate limit but an actual bitrate limit. So the hint is less a hint than a statement of network policy IMO. That may stregthen @Kevsy's point of view above.

[ihlar]

See https://datatracker.ietf.org/doc/draft-tan-sconepro-netneutrality/ for extended discussion.

[bryantanwc]

In the draft listed by @ihlar , I have made reference to the BEREC guidelines (EU) and internet society document 2015 (for US and other markets). The intent of aforementioned draft is not to frame it as a written statement verifying compliance with net neutrality – but instead to frame it around the goal of ensuring, through collaborative stakeholder input in the WG, that the proposed technical solution stays consistent with net neutrality principles as outlined, in various markets

[SpencerDawkins]

Now that we have added deliverables to the charter, I propose this issue should be addressed in the "SCONEPRO protocol" deliverable.