Internet DRAFT - draft-kaippallimalil-media-hdr-wireless-networks
draft-kaippallimalil-media-hdr-wireless-networks
Transport Area Working Group J. Kaippallimalil
Internet-Draft Futurewei
Intended status: Informational S. Gundavelli
Expires: 22 April 2023 Cisco
19 October 2022
Media Header Extensions for Wireless Networks
draft-kaippallimalil-media-hdr-wireless-networks-00
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/.
Kaippallimalil & GundavellExpires 22 April 2023 [Page 1]
Internet-Draft Media Header Extension Wireless Networks October 2022
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 22 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Information on Media Packet Data . . . . . . . . . . . . . . 4
4. Metadata Transport . . . . . . . . . . . . . . . . . . . . . 5
4.1. Media Over QUIC Header Extension . . . . . . . . . . . . 6
4.2. UDP Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. MASQUE Encapsulation . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
Kaippallimalil & GundavellExpires 22 April 2023 [Page 2]
Internet-Draft Media Header Extension Wireless Networks October 2022
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.
Kaippallimalil & GundavellExpires 22 April 2023 [Page 3]
Internet-Draft Media Header Extension Wireless Networks October 2022
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
Kaippallimalil & GundavellExpires 22 April 2023 [Page 4]
Internet-Draft Media Header Extension Wireless Networks October 2022
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
Kaippallimalil & GundavellExpires 22 April 2023 [Page 5]
Internet-Draft Media Header Extension Wireless Networks October 2022
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
Kaippallimalil & GundavellExpires 22 April 2023 [Page 6]
Internet-Draft Media Header Extension Wireless Networks October 2022
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, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8. Informative References
[draft-ietf-mops-streaming-opcons-12]
IETF, "Operational Considerations for Streaming Media",
August 2022.
[draft-ietf-mops-ar-use-case-06]
IETF, "Media Operations Use Case for an Extended Reality
Application on Edge Computing Infrastructure", August
2022.
[draft-gruessing-moq-requirements-02]
IETF, "Media Over QUIC - Use Cases and Requirements for
Media Transport Protocol Design", March 2022.
[draft-ietf-tsvwg-options-18]
IETF, "Transport Options for UDP", July 2022.
Kaippallimalil & GundavellExpires 22 April 2023 [Page 7]
Internet-Draft Media Header Extension Wireless Networks October 2022
[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/info/rfc9297>.
[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<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)",
August 2022.
Authors' Addresses
John Kaippallimalil
Futurewei
United States of America
Email: john.kaippallimalil@futurewei.com
Sri Gundavelli
Cisco
United States of America
Email: sgundave@cisco.com
Kaippallimalil & GundavellExpires 22 April 2023 [Page 8]
