]> Huawei Technologies

China shihang9@huawei.com

Transport QUIC Internet-Draft This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization.

Introduction Nowadays, the media application are usually able to dynamically adjust the size and quality of the stream to adapt to the 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 and . 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 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. 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 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 the privacy, the metadata MAY be encrypted and only decrypted by 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 which 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

Architecture of the intermediary

shows the architecture of the optimization intermediary. The sender endpoint encode the metadata into the connection ID field (See ). The intermediary performs the related optimization based on the metadata. Since different applications may need to expose different metadata to the intermediary, a template is used to define the content and the format of metadata. The template is determined and distributed by a configuration agent. If the network between the intermediary and endpoints is not trusted by endpoints, the metadata MAY be encrypted. In this case, the parameter for encryption MUST be shared only to the authenticated intermediary through the configuration agent. The means of the authentication and the distribution of these parameters and template is not in the scope of this document.

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 is defined by a template and shared between an endpoint and the intermediary. For example, the media frame information in and the service requirement such as delay and importance in can be used as a template. If an intermediary acts as both the load balancer and the optimization point and they share the same trust relationship, the Metadata and the Server ID defined in can be put together and share the same Config Parameter. Otherwise, if a QUIC connection goes through both load balancer and optimization point, additional mechanism is needed for the coexist of the metadata and the Server ID. The detail will be worked out in the later version.

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 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 are able to dynamically adjust the size and quality of a stream to match available network bandwidth. However, catering to such media flows over a radio link where the capacity changes rapidly requires the buffers and QoS in general to be managed carefully. This draft proposes additional information about the media transported in each packet to manage the buffers and optimize the scheduling of radio resources. The set of information proposed here includes importance of the packet, burst length and time budget to be conveyed by the media application in a new UDP option. The metadata in the UDP option is used to provide the wireless network the flexibility to prioritize packets that are essential when the radio capacity is temporarily low, defer packets that can tolerate some additional delay, or even drop packets selectively in more extreme conditions. This draft defines media metadata, a new UDP option to carry this metadata and the operational aspects for using it between a UDP source and a on-path wireless entity. InterDigital InterDigital This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MOQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MOQ equivalent to what is possible for RTP. Cisco Systems Cisco Systems Cisco Systems This document describes a 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 Cisco 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 are able to dynamically adjust the size and quality of a stream to match available network bandwidth. However, catering to such media flows over a radio link where the capacity changes rapidly requires the buffers and QoS in general to be managed carefully. This draft proposes additional information about the media transported in each packet to manage the buffers and optimize the scheduling of radio resources. The set of information proposed here includes importance of the packet, burst length and time budget to be conveyed by the media application in a new UDP option. The metadata in the UDP option is used to provide the wireless network the flexibility to prioritize packets that are essential when the radio capacity is temporarily low, defer packets that can tolerate some additional delay, or even drop packets selectively in more extreme conditions. This draft defines media metadata, a new UDP option to carry this metadata and the operational aspects for using it between a UDP source and a on-path wireless entity.