Skip to main content

Media Header Extensions for Wireless Networks
draft-kaippallimalil-tsvwg-media-hdr-wireless-00

Document Type Active Internet-Draft (individual)
Authors John Kaippallimalil , Sri Gundavelli
Last updated 2022-10-20
Replaces draft-kaippallimalil-media-hdr-wireless-networks
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kaippallimalil-tsvwg-media-hdr-wireless-00
Transport Area Working Group                           J. Kaippallimalil
Internet-Draft                                                 Futurewei
Intended status: Informational                             S. Gundavelli
Expires: 23 April 2023                                             Cisco
                                                         20 October 2022

             Media Header Extensions for Wireless Networks
            draft-kaippallimalil-tsvwg-media-hdr-wireless-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 23 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 23 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 23 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 23 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 23 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 23 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 23 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 23 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 23 April 2023                 [Page 8]