Media Header Extensions for Wireless Networks

Wireless networks inherently experience large variations in link capacity due to a number of factors. These include the change in wireless channel conditions, interference between proximate cells and channels or as a result of the end user's movement. These variations in link capacity take place in a short time in the order of hundreds of milliseconds. End-to-end congestion control at the IP layer does not react fast enough to these changes. Media packets on the other hand demand both high throughput and low latency. They are adaptable, but when the feedback signal (i.e., via end-to-end congestion signaling) is of low resolution compared to the changes in the network, the result is that there is no means by which the application can adjust the flow rate just enough, or to signal which packet (or group of packets) have priority or which can tolerate more delay. If there are short periods of low radio channel capacity, random packet drops may also result in more damage than if a packet dropped is of a lower importance (e.g., encoding of an enhanced layer and not a base layer). 3GPP is currently studying possible enhancements in the wireless network for high bandwidth and low latency media flows. Some of the key issues discussed there include selective handling of packets of a media flow with the aim to improve scheduling and forwarding behavior in the wireless network. Media packets that are fully encrypted and carry fragments of multiple media streams in a packet are not easy to classify since it depends on the sets of media being encoded and the application's choices on packetization of the various streams. Examining or inferring based on patterns or other heuristics is expensive, unreliable and defeats the goal of minimizing sojourn time in the wireless network. The simplest way is to examine metadata inserted by the application as a basis for classification in the wireless network and is what is proposed in . Metadata inserted by an application may be transported using one of several protocols. Possible options include carrying this information in an media extension header for QUIC , as part of a UDP option or using MASQUE encapsulation between the wireless network and application server . The trade-off in terms of lookup efficiency, application APIs for managing the metadata, protocol overhead and other aspects are discussed 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.

For media flows that require high bandwidth and low latency, the assumption is that the upstream wired network has more capacity than the wireless network, i.e., the radio network is the bottleneck. Link capacity in the wireless network changes far too quickly for end-to-end congestion control to work well by itself for such media flows. Wireless conditions will have changed several times over in the time that end-to-end congestion is signaled and so it remains a low resolution signal with respect to radio condition changes. The need to provide high bandwidth and cope with changing link conditions mean that the radio network should maintain long packet queues for link layer scheduling, and conversely short queues for low latency. This need for a managed or bounded latency queue at the link layer in turn depends on transport layer queues providing sufficient packets to utilize the available radio link capacity and only a small number of packets if the radio link capacity available at the next instant is limited. Therefore, priority of a packet, timestamp and burst size can allow the transport layer to prioritize and manage the queues when capacity is limited. Flows that use RTP/SRTP for transport can classify the packets by inspecting the media headers or metadata found in the RTP/SRTP headers and extension headers. However, when media information is transported over HTTP/3 or other fully encrypted transports, there is no simple way to infer the contents of the packet. Encryption results in media headers not being visible and if multiple media streams are concurrently in progress the resulting packetization obscures it further. HTTP/3 media is of particular interest because of its potential for low latency. Two issues to address the issues outlined here are described further in the sections below. One is about what metadata the wireless network needs and that the application can provide. The second is with regard to how to transport the metadata from the application to the wireless network.

Media packets are encoded and formatted to enable efficient and reliable processing of the data at both the encoding and decoding endpoints. Media may consist of audio, live video, static pictures and overlaid objects among others. Each of these may have different tolerance to delays in the network, encoding resiliency (e.g, FEC) or even subjective importance (e.g., a loss of a video base layer I-frame packets may be more significant than enhanced layer P-frame). Media encoding is evolving and modern codecs use complex prediction structures and make various dynamic decisions in the encoding process. However, it is expected that there are differences in priority, delay and other factors across sets of packets. This is information that the wireless network needs to provide better a forwarding service especially when there is a high demand of network resources and poor radio conditions. The wireless network, unlike encoders and decoders, is not concerned with decoding the media, but rather on deciding the best forwarding options when its link capacity is limited. Since applications may deliver media across 5G, WiFi or wired networks the attempt should be for a minimal set of metadata that is useful for optimizing handling of media packets across (at least the wireless) networks. The proposal here is for a media application to provide a set of metadata about the packet that the wireless network inspects and uses to optimize handling during adverse radio conditions. Some information that is useful to wireless networks include the relative importance of a packet (or a group of packets), the number of packets in a burst and timestamps. Relative importance of a packet (or group of packets) is useful to provide some flexibility to the radio scheduler to prioritize packets that are essential during low capacity intervals and to defer packets that can tolerate some additional delay, or even drop the packet. For example, if some set of packets carry a stored video image that is predicted to be used later, it may be able to tolerate some additional delay over a real-time video encoding that is carried in another stream. Another parameter of use to the wireless network is the size of packet burst. The distribution of packets tend to be heavy tailed in many cases, for example the extended reality use case in . The number of packets in a burst can help the wireless scheduler to plan ahead of time for the amount of resources expected. Timestamps are useful for the network to aid in grouping packets or treating packets with a level of importance and time in a consistent manner. It is expected that forward error correction and HTTP/3 multistreaming could result in complex encoding of multiple media streams across each packet. Details on each of these parameters and their use will be specified in a subsequent version of this draft.

Transport of metadata between the application and wireless network may be based on one of several protocol options but it would be preferable to have one mechanism (or limited number) so that wireless network entities do not have to support a large number of options. Some considerations include the ease with which an application can encode the metadata in a transport header, compactness and efficiency for lookup in the wireless network as this is applied per packet, and the security of the metadata itself (not unique to wireless networks). Some options that have been identified in the 3GPP study as potential candidates include media over QUIC extension header , UDP options or using MASQUE encapsulation between the 3GPP network and application server . The sub-sections below explore each of these options further but a full evaluation needs further discussion in the relevant IETF working groups.

Media over QUIC extension headers, if extended to support metadata identified in , can provide information to wireless networks on media carried in HTTP/3. MOQ can provide metadata per media packet similar to RTP headers or SRTP extension headers that are being considered in 3GPP for classifying packets and providing extended QoS handling in 5G radio. The MOQ extension header would be similarly efficient for a wireless network to process per packet since it is at a fixed offset. The assumption in this scenario is that mechanisms to encode MOQ extension header metadata and related security considerations are not specific to this draft for wireless networks.

A new UDP option that conforms to would need to be developed for carrying wireless network media metadata. The authors consider that UDP options would be efficient similar to MOQ and since it is at the UDP layer, it may be applicable to not only HTTP/3 media but also RTP/SRTP for any further extensions related to wireless networks. One aspect that needs to be evaluated further is with regard to APIs and the ease with which applications can encode such metadata in UDP options. Other aspects of using UDP options in this manner need to be discussed further.

In this solution, a MASQUE tunnel between the user plane function (UPF) and the application server is setup for the express purpose of allowing the application to send metadata to the UPF. The metadata in this case is sent in a new HTTP capsule . In theory this requires less coordination with IETF but may still need application support in terms of defining an agreed set of metadata and consideration on HTTP capsule APIs for the application to encode the metadata in the MASQUE header. This method may also requires the wireless network to additionally encapsulate/decapsulate and encrypt/decrypt each packet at the UPF to obtain this metadata and forward the packet. In terms of security, since the entire MASQUE tunnel is encrypted, no additional security measures are needed.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document should not affect the security of the Internet. Security aspects in relation to the transport of metadata is considered as an inherent part of the mechanisms and uses either integrity protection or encryption.