Internet-Draft Media Header Extension Wireless Networks October 2022
Kaippallimalil & Gundavelli Expires 23 April 2023 [Page]
Workgroup:
Transport Area Working Group
Internet-Draft:
draft-kaippallimalil-tsvwg-media-hdr-wireless-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Kaippallimalil
Futurewei
S. Gundavelli
Cisco

Media Header Extensions for Wireless Networks

Abstract

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. 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 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 relative importance of the packet, burst length and timestamp to be conveyed by the media application in a header extension. This can be 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.

Another aspect considered here is the means by which the media packet information is transported. Potential solutions include carrying this information in Media over QUIC extension headers, UDP options, or in a MASQUE encapsulation between the application server and wireless network entity.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 April 2023.

Table of Contents

1. Introduction

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 [TR.23.700-60-3GPP] 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 Section 3.

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 [draft-gruessing-moq-requirements-02], as part of a UDP option [draft-ietf-tsvwg-options-18] or using MASQUE encapsulation between the wireless network and application server [RFC9298]. The trade-off in terms of lookup efficiency, application APIs for managing the metadata, protocol overhead and other aspects are discussed in Section 4.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Problem Statement

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.

3. Information on Media Packet Data

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 [draft-ietf-mops-ar-use-case-06]. 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.

4. Metadata Transport

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 [draft-gruessing-moq-requirements-02], UDP options [draft-ietf-tsvwg-options-18] or using MASQUE encapsulation between the 3GPP network and application server [RFC9298]. The sub-sections below explore each of these options further but a full evaluation needs further discussion in the relevant IETF working groups.

4.1. Media Over QUIC Header Extension

Media over QUIC extension headers, if extended to support metadata identified in Section 3, 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.

4.2. UDP Options

A new UDP option that conforms to [draft-ietf-tsvwg-options-18] 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.

4.3. MASQUE Encapsulation

In this solution, a MASQUE [RFC9298] 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 [RFC9297]. 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.

5. IANA Considerations

This memo includes no request to IANA.

6. 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.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

8. Informative References

[draft-ietf-mops-streaming-opcons-12]
IETF, "Operational Considerations for Streaming Media", .
[draft-ietf-mops-ar-use-case-06]
IETF, "Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure", .
[draft-gruessing-moq-requirements-02]
IETF, "Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design", .
[draft-ietf-tsvwg-options-18]
IETF, "Transport Options for UDP", .
[RFC9297]
Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, , <https://www.rfc-editor.org/info/rfc9297>.
[RFC9298]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298, DOI 10.17487/RFC9298, , <https://www.rfc-editor.org/info/rfc9298>.
[TR.23.700-60-3GPP]
3rd Generation Partnership Project (3GPP), "Study on XR (Extended Reality) and media services (Release 18)", .

Authors' Addresses

John Kaippallimalil
Futurewei
United States of America
Sri Gundavelli
Cisco
United States of America