**Session Date/Time:** 23 Jul 2024 16:30

# sconepro

## Summary

This session was a BoF to discuss a potential IETF working group focused on improving adaptive bitrate (ABR) video delivery by explicitly signaling network throughput properties to clients.  The session covered the problem statement, a proposed charter, and open questions raised at the previous BoF.  A key point of discussion centered on the scope of the working group, particularly regarding the definition of a "flow" and whether the solution should be client-initiated or provide unsolicited information. The session concluded with a poll indicating interest in the topic and a commitment to revising the charter based on the feedback.

## Key Discussion Points

*   **Problem Statement:** ABR video shaping by networks often leads to poor user experience due to slow convergence and interactions with congestion control. The goal is to explicitly inform the application about bitrate caps.
*   **Scope:** There was significant debate regarding the scope, including the definition of "flow," whether to support only Quick-based streams, and whether the signaling should be client-initiated (opt-in) or unsolicited.
*   **Privacy:** Privacy implications were discussed, particularly regarding the potential for exposing subscriber information or traffic types. It was noted that networks already have mechanisms to identify video traffic.
*   **Security and Trust:** The session explored how to ensure that the network-provided throughput information can be trusted and how to handle cases where the information is incorrect or misleading.
*   **Net Neutrality:** The potential impact on net neutrality was raised, with the consensus being that the proposal is a response to existing practices and does not fundamentally change the net neutrality landscape.
*   **Definition of ABR:** Clarification was requested on what exactly the group means by ABR, accounting for different use cases and latency requirements. The current understanding is ABR means that a client is able to switch between video encodings as part of a video playback or video experience.
*   **Four-Tuple vs Connection ID:** A core discussion revolved around the right abstraction to use for identifying the traffic to which the network signal applies. Options included a UDP four-tuple, a QUIC connection ID, or a more abstract identifier.
*   **Congestion Control:** There was a lot of discussion that this proposal should *not* conflict with or replace congestion control.

## Decisions and Action Items

*   **UDP Four-Tuple:** There was a consensus, with no raised objections, to initially update the Charter to reflect the identifier for a flow to be based on the UDP four-tuple that is carrying the Quick connection, with the understanding that this may be refined in the working group.
*   **Charter Revision:** The charter will be revised based on feedback received during the session. This will include clarifying the definition of "flow", adding a more extensive problem statement, reflecting that the stream is carrying ABR, and considering the comments made in the list.

## Next Steps

*   Revise the charter based on the feedback received at the BoF, incorporating the UDP four-tuple definition and addressing other concerns.
*   Continue discussions on the "sad-cdn" mailing list.