]> Huawei Technologies

China shihang9@huawei.com

China Unicom

hanmy12@chinaunicom.cn

Transport QUIC Internet-Draft This document describes a mechanism to carry the metadata in the QUIC connection ID to communicate with the intermediary. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Nowadays, media applications are usually able to dynamically adjust the size and quality of the stream to adapt to fluctuating network conditions. However, for the high throughput and low latency media traffic, adaptation only by the endpoint is not good enough, especially when the network condition is challenging, such as the wireless networks discussed in . To this end, it is desirable to have the intermediary performing optimization for the endpoint. For example, low-priority packets can be dropped to save the resource when the network is congested. One example of such an intermediary is the relay in the Media over QUIC working group. To quote the charter from the MoQ working group. "Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently." "Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on." Due to the end-to-end encryption of the QUIC, the intermediary does not have the necessary metadata to perform optimization. A similar problem exists when the media is encrypted and transferred using SRTP . To solve the problem, defines an extension of the RTP header containing the video frame information. This document defines an extension of the QUIC header, using the connection ID to carry the necessary metadata. To mitigate the linkability between the multiple connection IDs of the same connection and protect privacy, the metadata MAY be encrypted and only decrypted by an authenticated intermediary. Similar to , a configuration agent is used to distribute the encryption parameters and the template of the metadata.

Terminology This document uses terms in the :

• "client" and "server" refer to the QUIC endpoint.
• Intermediary refers to a network element that forwards QUIC packets and does not possess the QUIC connection keys. Such an intermediary can be QUIC proxy defined in the MASQUE working group, wireless node described in the , and relay defined in the Media over QUIC working group.
• CID: Connection ID in the QUIC header.
• Configuration agent: An entity that distributes the encryption parameter and the template of the metadata field.

All wire formats will be depicted using the notation defined in .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Architecture

Levarage Metadata In QUIC CID to communicate with intermediary

shows the architecture of the optimization intermediary. The sender, which can be either the client or server based on the direction of communication, incorporates metadata into the connection ID field as outlined in the referenced section (See ). This metadata allows the intermediary to execute optimizations tailored to the information provided. Given that various applications may require the disclosure of distinct metadata to the intermediary, a standardized template is adopted to specify the metadata's content and structure. There are two primary methods for obtaining this template:

1. For each category of application, a specific template is crafted and cataloged within a new IANA registry. This approach leverages the global accessibility of the template definition, eliminating the need for its distribution by the configuration agent. The responsibility for developing these templates falls to the respective working groups or documents, which is beyond the scope of this document.
2. The configuration agent, operating within its domain, defines and disseminates the template. This strategy ensures the template's relevance and effectiveness is confined to the domain under the agent's control, tailored according to the capabilities of the network devices present.

If the network between the intermediary and endpoints is not trusted, the metadata MUST be encrypted. In such scenarios, the encryption parameters must be exclusively shared with authenticated intermediaries, potentially via the configuration agent. A viable encryption strategy might involve adopting the algorithm proposed in , ensuring the security of the metadata. The metadata field can also be modified by the intermediary, enabling the intermediary to pass the signal such as throughput advice as defined by SCONE WG to the end host.

Structured Connection ID

Format of structured CID

The format of the structured connection ID is shown in . The content and the format of the metadata field are defined by a template, carrying the information such as media characteristics in and metadata in

Coexistence with QUIC Load Balancer As both the Metadata and Server ID share the same field within the Connection ID (CID), it's crucial to devise mechanisms that prevent conflicts and ensure their seamless coexistence. If an intermediary serves dual roles as both the load balancer and the optimization node, and if both entities are underpinned by a unified trust relationship, then it is feasible to consolidate the Metadata and the Server ID specified in . This consolidation allows for the utilization of a singular Config Parameter and a shared encryption/decryption methodology. Conversely, if the load balancer and the optimization node are separated, the Server ID and the Metadata needs to be segregated too. One option is to split the CID into two segments: one for the Server ID and the other for the metadata. Each segment would be governed by its own set of Config Parameters and subjected to individual encryption protocols, ensuring the integrity and segregation of the transmitted information.

Security Considerations TBD

References Normative References This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Futurewei Cisco Tencent America LLC Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Note: The solution in this draft will be revised to address requirements defined in [draft-kwbdgrr-tsvwg-net-collab-rqmts]. Cisco Systems Cisco Systems Cisco Systems This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec- specific information. Google Microsoft Private Octopus Inc. QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. Futurewei Cloud Software Group Holdings, Inc. Cisco Cloud Software Group Holdings, Inc. Tencent America LLC Orange Collaborative signaling from host-to-network (i.e., client-to-network and server-to-network) can improve the user experience by informing the network about the nature and relative importance of packets (frames, streams, etc.) without having to disclose the content of the packets. Moreover, the collaborative signaling may be enabled so that clients and servers are aware of the network's treatment of incoming packets. Also, client-to-network collaboration can be put in place without revealing the identity of the remote servers. This collaboration allows for differentiated services at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission), or through cooperation of server/client and the network. This document lists some use cases that illustrate the need for a mechanism to share metadata and outlines host-to-network requirements. The document focuses on signaling information about a UDP transport flow (UDP 4-tuple).