Skip to main content

Media Handling Considerations for Wireless Networks
draft-kaippallimalil-tsvwg-media-hdr-wireless-04

Document Type Active Internet-Draft (individual)
Authors John Kaippallimalil , Sri Gundavelli , Spencer Dawkins
Last updated 2024-02-14
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-04
Transport and Services Working Group                   J. Kaippallimalil
Internet-Draft                                                 Futurewei
Intended status: Informational                             S. Gundavelli
Expires: 17 August 2024                                            Cisco
                                                              S. Dawkins
                                                     Tencent America LLC
                                                        14 February 2024

          Media Handling Considerations for Wireless Networks
            draft-kaippallimalil-tsvwg-media-hdr-wireless-04

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 for an application to adapt.  Media
   applications on the other hand demand both high throughput and low
   latency, and may adjust the size and quality of a stream to network
   bandwidth available or dynamic change in content coded.  However,
   catering to such media flows over a radio link with rapid changes in
   capacity requires the buffers and congestion to be managed carefully.
   Wireless networks need additional information to manage radio
   resources optimally to maximize network utilization and application
   performance.  This draft provides requirements on metadata about the
   media transported, its scalability, privacy, and other related
   considerations.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://spencerdawkins.github.io/media-hdr-wireless/#go.draft-
   kaippallimalil-tsvwg-media-hdr-wireless.html.  Status information for
   this document may be found at https://datatracker.ietf.org/doc/draft-
   kaippallimalil-tsvwg-media-hdr-wireless/.

   Discussion of this document takes place on the TSVWG Working Group
   mailing list (mailto:tsvwg@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/tsvwg/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/tsvwg/.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 1]
Internet-Draft           Media Header Extensions           February 2024

   Source for this draft and an issue tracker can be found at
   https://github.com/https://github.com/SpencerDawkins/media-hdr-
   wireless.

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 17 August 2024.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Media Stream and Packet Handling Requirements . . . . . . . .   6
     3.1.  Requirement 1: Classification of downlink media frames  .   6
       3.1.1.  Identification of media frames  . . . . . . . . . . .   7
       3.1.2.  Relative Priority of media frames . . . . . . . . . .   7
       3.1.3.  Tolerance to delay of media frames  . . . . . . . . .   7
     3.2.  Requirement 2: Classification of downlink streams . . . .   8
       3.2.1.  Identification of media streams . . . . . . . . . . .   8
       3.2.2.  Relative priority of media streams  . . . . . . . . .   8

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 2]
Internet-Draft           Media Header Extensions           February 2024

       3.2.3.  Tolerance to delay of media streams . . . . . . . . .   8
     3.3.  Requirement 3: Size of a burst of packets . . . . . . . .   9
     3.4.  Requirement 4: Jitter . . . . . . . . . . . . . . . . . .   9
     3.5.  Requirement 5: Detection of loss of packets . . . . . . .   9
     3.6.  Requirement 6: Privacy Considerations . . . . . . . . . .  10
     3.7.  Requirement 7: Scalable to large number of media flows  .  10
     3.8.  Requirement 8: Continuity following user mobility . . . .  10
   4.  Non-Requirements  . . . . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Normative References  . . . . . . . . . . . . . . . . . . . . .  12
     Informative References  . . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Solution: Metadata to Classify Media Packets . . . .  13
     A.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
     A.2.  Metadata Parameters . . . . . . . . . . . . . . . . . . .  15
       A.2.1.  Stream Flag . . . . . . . . . . . . . . . . . . . . .  15
       A.2.2.  MDU-Stream Counter  . . . . . . . . . . . . . . . . .  16
       A.2.3.  Importance  . . . . . . . . . . . . . . . . . . . . .  16
       A.2.4.  Tolerance to Delay  . . . . . . . . . . . . . . . . .  17
       A.2.5.  Burst Quantum Size  . . . . . . . . . . . . . . . . .  18
       A.2.6.  Sequence Number . . . . . . . . . . . . . . . . . . .  18
       A.2.7.  Timestamp . . . . . . . . . . . . . . . . . . . . . .  19
     A.3.  Configuring Obfuscated Codes  . . . . . . . . . . . . . .  19
     A.4.  Transport of Metadata . . . . . . . . . . . . . . . . . .  21
       A.4.1.  MED UDP Option  . . . . . . . . . . . . . . . . . . .  21
       A.4.2.  OFC UDP Option  . . . . . . . . . . . . . . . . . . .  22
     A.5.  IANA Considerations . . . . . . . . . . . . . . . . . . .  22
     A.6.  Security Considerations . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   Wireless networks inherently experience large variations in link
   capacity due to several factors.  These include the change in
   wireless channel conditions, interference between proximate cells and
   channels or because of the end user movement.  These variations in
   link capacity can be in the order of a millisecond.  End-to-end
   congestion control at the IP layer does not react fast enough to
   these changes when a combination of high throughput and low latency
   are required.  Media packets on the other hand can demand both high
   throughput and low latency, and many emerging applications are
   expected to increase the strain on radio network capacity and
   utilization.  The application can adapt, but when the feedback signal
   (i.e., via end-to-end congestion signaling and application level
   feedback) is of low resolution or frequency compared to the rapid
   (but transient) changes in the wireless network, the application can

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 3]
Internet-Draft           Media Header Extensions           February 2024

   settle to a longer-term average sending rate that is well below the
   capacity available.  One option is for the application to increase
   the sending rate to match the radio network capacity available in
   theory.  If the application increases the sending rate aggressively,
   it can result in packet loss because the radio network keeps smaller
   buffers to ensure low latency for these flows.  Low latency for the
   media flow and maximal usage of radio network capacity without
   affecting media application performance is not easy to realize in
   practice.

   With the aim of providing low latency, maximizing radio network
   resource utilization and improving media application performance,
   3GPP studied QoS and other enhancements in the wireless network in
   [TR.23.700-60-3GPP].  The findings of the study are now standardized
   in [TR.23.501-3GPP].  The recommendations include providing the
   destination wireless network (where the wireless endpoint is located)
   with information on groups of media packets that should be handled
   similarly (e.g., all packets of a video I-frame), the importance of a
   group of media packets relative to other such groups of packets as
   well as delay and packet bursts.  Since media frames vary in size
   based on the codec, the content encoded and multistreaming, the
   wireless network can use the classification to make optimal choices
   for traffic shaping.

   The specification in [TR.23.501-3GPP] relies on inspecting RTP and
   media payload headers for classifying packets on the downlink/
   destination radio network.  Inspection of unencrypted RTP packets
   depend on deep packet inspection and require significant effort to
   lookup the respective headers for classifying the media packet.
   However, with fully encrypted media streams that use QUIC or other
   encrypted media transport, inspection of the media payload headers by
   the downlink wireless router is not possible.

   Figure 1 gives a high level overview of the e2e network, media
   transport and control plane for which additional information is
   needed to optimize resources in the wireless network.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 4]
Internet-Draft           Media Header Extensions           February 2024

   +--------+            E2E feedback (e.g., RCTP)          +--------+
   |  (app) <-----------------------------------------------> (app)  |
   |    |   |                  +--------+                   |   |    |
   |    |   |  media payload   |        |     media payload |   |    |
   |(trnsprt)<-----------------| (QoS)  |<------------------(trnsprt)|
   |        |     (      )     |        |       (      )    |        |
   +--------+   ( Wireless )   +--------+     (IP Network)  +--------+
     Client      (Network)     Wireless        (       )      Server
                   (___)        Router           (___)

                        CSP                                    CAP
              |------------------------|                  |----------|

                   Figure 1: E2E Media transport overview

   Media packets from the server in a Content and Application Provider
   (CAP) is sent to a user (client) attached to a wireless router in a
   Communication Service Provider (CSP).  Media traffic sent downlink
   from the wireless router is shaped to provide optimal application
   performance and network utilization.

   In many scenarios that require low latency media delivery, the server
   and wireless router have established relationships and contractual
   agreements to optimize the delivery of media flows.  For example, the
   CAP (Content and Application Provider) and CSP (Communication Service
   Provider) may have a limited domain ([RFC8799]) that manages trust
   and configures policies related to the delivery of content.  The
   server and wireless router are located in networks operated by CAP
   and CSP respectively.  The transit (IP) network in between is either
   a trusted network that is managed and operated by the CSP/CAP, or the
   CSP/CAP use security gateways at the boundaries of their network to
   encrypt all traffic flowing between the CAP and CSP.  Thus, the
   requirements in Section 3 are not expected to satisfy sending
   metadata between arbitrary servers and wireless routers located
   across a wide area network.  Section 3 provides requirements to
   support the provision of information/metadata sent from the CAP to
   the CSP to realize optimal management of radio network resources and
   application performance.

2.  Conventions and Definitions

   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, et al.   Expires 17 August 2024                 [Page 5]
Internet-Draft           Media Header Extensions           February 2024

2.1.  Definitions

   CAP Content and Application Provider
   CSP Communication Service Provider
   MDU Media Data Unit; a unit of application information.

   An MDU may span multiple packets and are also sometimes referred to
   as media frames.

   Traffic shaping in this document refers to QoS management at the
   wireless router to delay or drop packets (or groups of packets) of
   lower priority to achieve bounded latency and high throughput.

3.  Media Stream and Packet Handling Requirements

   Wireless networks shape traffic and schedule radio resources to adapt
   to rapid changes in channel conditions.  When media applications
   demand high throughput and low latency, the rate at which an
   application can adapt based on congestion feedback is not sufficient
   to maximize application performance and utilize available capacity
   optimally.  Information to classify packets, groups of packets or
   streams by priority and tolerance to delay is needed help the
   wireless network.  The requirements here outline the information
   needed by the wireless network and the related requirements for
   privacy, performance and scalability.

   The assumption in the requirements below are that they apply to low
   latency media transports (e.g, RoQ [I-D.ietf-avtcore-rtp-over-quic]),
   RTP-cryptex [RFC9335] and WebRTC [RFC8854].  In the requirements
   below, a stream refers to a data flow from a sender to receiver
   (e.g., SRTP video packets, QUIC stream carrying audio).  A transport
   connection may carry one or more (media) streams from sender to
   receiver.

3.1.  Requirement 1: Classification of downlink media frames

   Feedback provided by ECN/L4S to the server (UDP sender) is not fast
   enough to adjust the sending rate when available wireless capacity
   changes significantly in very short periods of time (~ 1
   millisecond).
   Differentiating using multiple DSCP codes does not provide the
   resolution required to classify media frames and adapt to changes in
   coding due to dynamic content or resulting from network conditions.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 6]
Internet-Draft           Media Header Extensions           February 2024

   Relative priority of media frames, tolerance to delay, identification
   of media frame boundaries are provided by the application to optimize
   traffic shaping at the wireless router.  Alternatively, an
   application may prefer to provide only the information about streams
   and their relative priority (see Section 3.2).  In such cases it does
   not provide any information to classify media frames.

3.1.1.  Identification of media frames

   A wireless router should treat all packets of an MDU (media frame) in
   the same manner for optimal application performance.  Random, or tail
   drops that span media frame boundaries may result in the decoder
   being unable to decode many more media frames.

   The application should provide information that allows the wireless
   router to detect the start, end and set of packets of an MDU (media
   frame).  In cases where the wireless network has to drop or delay
   processing, all packets of the MDU are treated in the same manner.

3.1.2.  Relative Priority of media frames

   Relative importance of a packet (or media frame) provides the
   priority level of one media frame over another media frame in a
   stream.  The application server determines the importance based on
   the media encoded in the media frame (e.g., a base layer video
   I-frame has higher priority than an enhanced layer P-frame).
   Importance may be used to determine drop priority in cases of extreme
   congestion in the wireless network.

3.1.3.  Tolerance to delay of media frames

   Some media frames may be able to tolerate more delay over the wire
   than others (e.g., live media frames require very low latency while a
   background image for augmented reality may be delivered with more
   delay tolerance).  Even when the media payload is not encrypted, the
   network has no means to distinguish these different requirements.

   If the application can indicate that an MDU can tolerate high delay
   the wireless router can opt to delay packets rather than drop during
   transient congestion periods.  The application should also be able to
   convey that in some cases it has no specific information about
   relative delays, or expects the same delay tolerance for all media
   frames.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 7]
Internet-Draft           Media Header Extensions           February 2024

3.2.  Requirement 2: Classification of downlink streams

   In some deployments, multiple media streams with different priorities
   are sent in a single transport connection (e.g., WebRTC [RFC8854],
   QUIC transports for multimodal media, audio, video, control,
   haptics).  In such cases, an application may want to prioritize one
   stream over another in the event of extreme congestion (e.g., audio
   stream prioritized over video stream).

   The application may prefer to provide only the information about
   streams and their relative priority, and in such cases it does not
   provide any information to classify media frames (see Section 3.1).
   In this case, the application conveys to the wireless network the
   relative priority of media streams in a single transport connection.

3.2.1.  Identification of media streams

   Multiple streams of media are sometimes delivered over a single
   transport connection where the payload and stream headers are
   encrypted (e.g., QUIC).  A wireless router cannot identify the
   streams by inspecting the header fields (e.g., connection identifier
   in QUIC).

   The application should provide a means to identify one encrypted
   media stream from another to allow the wireless router to provide
   differentiated QoS treatment for each stream.

3.2.2.  Relative priority of media streams

   Relative importance of a media stream is the priority level of one
   media stream over another stream in the transport connection.  The
   application server determines the importance based on the media
   encoded in the stream.  Importance may be used to determine drop
   priority in cases of extreme congestion in the wireless network.

3.2.3.  Tolerance to delay of media streams

   Some media streams may be able to tolerate more delay over the wire
   than others (e.g., a stream carrying a background image for augmented
   reality may be delivered with more delay tolerance).  Even when the
   media payload is not encrypted, the network has no means to
   distinguish these different requirements.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 8]
Internet-Draft           Media Header Extensions           February 2024

   If the application can indicate that a stream can tolerate high delay
   the wireless router can opt to delay packets rather than drop during
   transient congestion periods.  The application should also be able to
   convey that in some cases it has no specific information about
   relative delays, or expects the same delay tolerance for all media
   streams.

3.3.  Requirement 3: Size of a burst of packets

   Media flows can have large and unexpected variations in packet bursts
   due to dynamic changes in content, server estimation of network
   conditions and pacing behavior.  Encoding of live video, and
   multimodal media can only increase the burst size that a server has
   to contend with sending out in a relative smoothed out manner.  The
   burst size is observable on the wire, but can only be determined by
   the end of the burst of packets.  Wireless networks on the other hand
   cannot reserve resources for the maximum burst size as that will lead
   to poor utilization of the radio resources.

   The server should provide expected size of a burst of packets at the
   beginning of the burst to allow the scheduler to reserve sufficient
   resources (and avoid have too few resources that lead to a tail
   drop).  Application servers that are not able to reliably estimate
   the burst size at the beginning of a burst should not provide any
   information about the burst size.

3.4.  Requirement 4: Jitter

   Packets of a burst that experience a high level of jitter are likely
   experiencing higher than usual delay before arriving at the wireless
   network.  The wireless router can use packet timestamps to derive
   jitter and optimize downlink scheduling.

   A timestamp with resolution to the microsecond level (e.g., short
   format in [RFC5905]) is sufficient for these purposes.

3.5.  Requirement 5: Detection of loss of packets

   The wireless router should be aware of any loss of packets belonging
   to a media frame.  For example, the loss of a packet that is a start
   or end of a media frame can cause confusion in estimating media frame
   boundaries.  However, the wireless router does not re-order packets
   arriving out of order at the wireless router as this will increase
   latency experienced by the flow.

   The server should provide a sequence number that identifies the
   sequence of packets for a transport connection carrying the media
   flows.

Kaippallimalil, et al.   Expires 17 August 2024                 [Page 9]
Internet-Draft           Media Header Extensions           February 2024

3.6.  Requirement 6: Privacy Considerations

   Encrypted media payloads along with temporary IP addresses between a
   server and user (client) provide a measure of privacy for the content
   and the identity of the user.  It should however be noted that media
   flows (e.g., encrypted video payloads in SRTP) exhibit a pattern of
   bursts and intervals that amounts to a signature and is vulnerable to
   frequency analysis.  To avoid this kind of frequency analysis, media
   sent by the server would need to be scheduled or multiplexed
   differently to each user/recipient.  This may be possible in
   transports like QUIC which allows flexibility in scheduling each
   stream.  Transports like QUIC also fully encrypt the entire stream
   and therefore no media headers are observable on path either.  The
   security aspects of the media payload/ transport are not in the scope
   of these requirements and is described here only to provide context
   for metadata privacy.  Privacy considerations for the metadata itself
   should ensure that no additional information about either the content
   or the user of the content is revealed.

   Some of the metadata like the size of a burst of packets, sequence
   number and timestamp are information that can be plainly observed or
   inferred by an entity on path.  These and all other metadata sent
   from server to the wireless router are vulnerable to modification on
   path.  All metadata should therefore have secure integrity protection
   (e.g., a secure message digest) to detect any modification or
   tampering on path.

3.7.  Requirement 7: Scalable to large number of media flows

   There may be a large number of media flows handled by the server and
   wireless router, and more generally between CAP and CSP.

   Per flow information (state) at a wireless router for optimizing the
   flow can negate the advantages offered as the number of flows handled
   increase.  The metadata other state information that a wireless
   router has to maintain for each additional media flow it handles
   should be very low or none.

3.8.  Requirement 8: Continuity following user mobility

   The general trend in wireless networks is to distribute the wireless
   router closer to the user.  This can help with low latency but it
   results in more handovers from one router to another as the user
   moves.  The number of handovers also increase as a user moves faster
   or the media session lasts longer.

   There should no additional delay incurred during handover in
   configuring/setting up the metadata of a media session in progress.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 10]
Internet-Draft           Media Header Extensions           February 2024

4.  Non-Requirements

   Metadata resulting from these requirements are to be used by the
   wireless router (connection termination side) for shaping the
   downlink traffic.  However, this document does not specify how this
   information should be used by the wireless router.

   Similarly, an application provides this information to the transport
   stack on the application server.  How the application conveys this
   information to the transport stack is out of scope of these
   requirements.

   Control plane feedback with measurements of packets lost and delay
   incurred may affect the sending rate.  Dropping less important
   application frames in the presence of very short term changes of
   available bandwidth should not directly lead to lowering the sending
   rate itself.  Some work may be needed to allow the application server
   to differentiate between the short term variability and the presence
   of congestion in the network, but is not in the scope of these
   requirements.

5.  IANA Considerations

   None.

6.  Security Considerations

   This document has no security considerations.

Acknowledgments

   Thanks to Tiru Reddy for extensive discussions on security, metadata
   and UDP options formats in this draft.

   Thanks to Dan Wing for input on security and reliability of messages
   for this draft.

   Xavier De Foy and the authors of this draft have discussed the
   similarities and differences of this draft with the MoQ draft for
   carrying media metadata.

   The authors wish to thank Mike Heard, Sebastian Moeller and Tom
   Herbert for discussions on metadata fields, fragmentation and various
   transport aspects.

   The authors appreciate input from Marcus Ilhar and Magnus Westerlund
   on the need to address privacy in general and Dan Druta to consider a
   common transport across various host to network signaling when

Kaippallimalil, et al.   Expires 17 August 2024                [Page 11]
Internet-Draft           Media Header Extensions           February 2024

   possible.  Ruediger Geib suggested that limiting the amount of state
   information that a wireless router has to keep for a flow should be
   minimized.

References

Normative References

   [I-D.ietf-avtcore-rtp-over-quic]
              Ott, J., Engelbart, M., and S. Dawkins, "RTP over QUIC
              (RoQ)", Work in Progress, Internet-Draft, draft-ietf-
              avtcore-rtp-over-quic-08, 12 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-
              rtp-over-quic-08>.

   [I-D.ietf-tsvwg-udp-options]
              Touch, J. D., "Transport Options for UDP", Work in
              Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-28,
              17 November 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tsvwg-udp-options-28>.

   [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/rfc/rfc2119>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5905>.

   [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/rfc/rfc8174>.

Informative References

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/rfc/rfc8799>.

   [RFC8854]  Uberti, J., "WebRTC Forward Error Correction
              Requirements", RFC 8854, DOI 10.17487/RFC8854, January
              2021, <https://www.rfc-editor.org/rfc/rfc8854>.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 12]
Internet-Draft           Media Header Extensions           February 2024

   [RFC9335]  Uberti, J., Jennings, C., and S. Murillo, "Completely
              Encrypting RTP Header Extensions and Contributing
              Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023,
              <https://www.rfc-editor.org/rfc/rfc9335>.

   [TR.23.501-3GPP]
              "3rd Generation Partnership Project; Technical
              Specification Group Servies and System Aspects; System
              architecture for the 5G System (5GS); Stage 2 (Release
              18)", March 2023.

   [TR.23.700-60-3GPP]
              "Study on XR (Extended Reality) and media services
              (Release 18)", August 2022.

Appendix A.  Solution: Metadata to Classify Media Packets

A.1.  Overview

   Section 1 has described the need for additional information to
   optimally handle low latency, high bandwidth flows in the wireless
   network due to rapid changes in link capacity in a wireless network.
   The aim of the solution here is to provide metadata that a wireless
   router on the connection termination side can use to shape traffic
   optimally.

   +--------+     E2E control/feedback (e.g., SDP, RCTP)    +--------+
   |  (app) <-----------------------------------------------> (app)  |
   |    |   |                 +------+                      |   |    |
   |    |   |      UDP-i      |      |UDP-i + UDP-o/metadata|   |    |
   |(trnsprt)<----------------| (QoS)|<<<<<<<<<<<<<<<<<<<<<<(trnsprt)|
   |        |     (      )    |      |       (      )       |        |
   +--------+   ( Wireless )  +------+     (IP Network)     +--------+
     Client      (Network)    Wireless       (       )        Server
                   (___)       Router         (___)

                        CSP                                    CAP
              |------------------------|                  |----------|

        Figure 2: UDP Media Payload and Metadata in outer UDP Packet

Kaippallimalil, et al.   Expires 17 August 2024                [Page 13]
Internet-Draft           Media Header Extensions           February 2024

   Figure 2 outlines the scenario where a media packet from a server
   (e.g., a media server or relay) is sent to a client (i.e., a wireless
   endpoint).  The server is located at a CAP (Content and Application
   Provider) and the client is at a CSP (Communications Service
   Provider) with a transit/IP network in between as in Figure 2.  Media
   packets with low latency and high bandwidth requirements are sent
   from the server to client in UDP packets (UDP inner, UDP-i in
   Figure 2).  Metadata is sent in an outer UDP encapsulation (UDP
   outer, UDP-o in Figure 2).

   The wireless router on the connection termination side uses the
   metadata including importance (or relative priority), packet burst
   size and delay tolerance to assist in shaping downstream traffic.
   Media frames that consist of multiple packets get the same QoS
   treatment when MDU/media frame information is sent by the server.  An
   alternative is for the server to send metadata to differentiate
   multiple streams and provide related QoS treatment.  The metadata in
   this solution support both options and the metadata parameters are
   described in Appendix A.2.

   There two UDP options proposed here to transport the metadata.  One
   option uses a new UDP option (MED) that send the metadata unencrypted
   between the server and wireless router.  When this option is chosen,
   the CAP, CSP and the IP transit network connecting them have the
   means to ensure that the traffic is secure.  For example, the server
   and wireless router located in adjacent edge data centers and
   connected by a managed IP network and bulk encryption of packets
   between the data centers.  Transport using MED is described in
   Appendix A.4.1.

   When there are fewer trust guarantees on the metadata path (or zero
   trust) between server and wireless router, the recommendation is to
   use metadata that is obfuscated (OFS).  This would use a new UDP
   option (OFS) and requires the secure configuration of obfuscated
   codes as described in Appendix A.3.  Transport using OFC is described
   in Appendix A.4.2.

   The MED and OFC UDP options are both able to convey relative priority
   (importance), tolerance to delay, size of a burst of packets and
   information to derive jitter and detect loss of packets.  Both MED
   and OFC support the above information for either media frames/MDU or
   streams.  MED does not require any preconfigured information but a
   control plane configuration (out of scope here) may be used to limit
   the combinations of information sent.  OFC on the other hand requires
   configured the codes that correspond to a set of information (see
   Appendix A.3) and that automatically limits the combinations of
   information.  Thus, the basic information in OFC or MED can be
   constrained by a control plane configuration to limit the possible

Kaippallimalil, et al.   Expires 17 August 2024                [Page 14]
Internet-Draft           Media Header Extensions           February 2024

   number of states that a wireless router has to consider.  Both UDP
   options also require no additional setup after a handover as OFCs are
   preconfigured per domain (CAP - CSP) and MED is sent unencrypted.

A.2.  Metadata Parameters

   This section describes the metadata parameters to satisfy the
   requirements identified in Section 3.  The metadata is designed to be
   used with both media frames (MDU) and media streams, but not at the
   same time.  A flag (Appendix A.2.1) determines if the server is using
   it for media frames or streams.  Some of the metadata parameters are
   carried differently for MED (Appendix A.4.1) and OFC (Appendix A.4.2)
   due to the way that they are configured and transported.  The
   description for each parameter covers how it is used with either MED
   or OFC based transport.

A.2.1.  Stream Flag

   This metadata can be used to send information that pertains to media
   frames or media streams.

              0
             +-+
             |S|
             +-+

           Value      Description
          -----------------------------------------------------
             S        Flag indicates media stream or frame
                       0  Media Frame
                       1  Media Stream

           Figure 3: Flag indicating media stream or media frame

   When the flag is set to "0" (media frame), the parameters Importance
   (Appendix A.2.3) and delay tolerance (Appendix A.2.4) provide
   information about each media frame (MDU).  When the flag is set tp
   "1" (media stream), importance and delay tolerance are for the media
   streams.  Other parameters including burst size, sequence number and
   timestamp apply in all cases.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 15]
Internet-Draft           Media Header Extensions           February 2024

A.2.2.  MDU-Stream Counter

   The MDU-Stream Counter field is a monotonically increasing value for
   every new media frame (MDU) or media stream.  All the packets of an
   MDU or stream carry the same Counter value.  The MDU-Stream Counter
   wraps around after 2^8 values and is thus able to represent 256
   concurrent MDUs or streams.  The counter field represents either an
   MDU counter or a stream counter based on the flag value in
   Appendix A.2.1.

   This field is only applicable to unencrypted MED.  When using
   obfuscated codes (OFS), the boundaries of an MDU are indicated by
   different OFS codes that are configured (see Appendix A.3).

                              0
                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |    Counter    |
                             +-+-+-+-+-+-+-+-+

                           Figure 4: MDU Counter

   The wireless network uses this field to provide consistent treatment
   to all packets that belong to the same MDU or stream.  In some cases,
   based on the priority and tolerance to delay and loss, the wireless
   router may delay or drop the sequence of packets that has the same
   MDU sequence value.  Media streams may carry an large or indefinite
   number of packets and hence the wireless router drops or delays a
   limited packets based on implementation.

   The Counter value is not itself associated to any set of media
   properties.

A.2.3.  Importance

   Importance represents the media characteristics of the set of packets
   that that form a media data unit (MDU) or media stream relative to
   the characteristics of another MDU/stream.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 16]
Internet-Draft           Media Header Extensions           February 2024

            0
            0 1 2 3 4 5
           +-+-+-+-+-+-+
           |  D  |  P  |
           +-+-+-+-+-+-+

         Value      Description
        -----------------------------------------------------
           D        Inter-MDU Dependency
                     000   No dependency Information provided
                     001   Independent
                     010   Base MDU
                     011   Enhanced MDU (dependent on previous base MDU)
           P        Priority level of MDU or stream
                     001   high priority
                     010   medium priority
                     011   low priority

                     Figure 5: Importance Parameter

   The server determines the priority of a packet in terms of how
   critical the loss of packets of an MDU or media stream is for the
   application.  Inter-MDU dependency has no significance for media
   streams and should always be set to "0".

   When OFCs are used, other values than independent/base/enhanced and
   specific to the media may be exchanged in the configuration signaling
   (see Appendix A.3).

A.2.4.  Tolerance to Delay

   This field conveys whether the MDU is useful if delayed in the
   network.  Since wireless resources change significantly over very
   short intervals, an indication that the MDU or media stream can
   tolerate delays allows the wireless network to delay rather than
   drop.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 17]
Internet-Draft           Media Header Extensions           February 2024

              0
              0 1
             +-+-+
             | L |
             +-+-+

           Value      Description
          -----------------------------------------------------
             L        Delay Tolerance
                        00   No delay tolerance information
                        01   always forward
                        10   limited value if delayed

                      Figure 6: Delay Budget Parameter

   The tolerance to delay along with data burst and importance
   (priority) can be used by wireless scheduler to plan for the
   appropriate level of resources.

A.2.5.  Burst Quantum Size

   This field represents a continuous burst of packets and is expressed
   in 3 Kbyte uniform quantums.  The size is chosen to provide
   sufficiently fine resolution to resource allocators in the wireless
   network and while being compact enough to represent a large burst of
   packets.

                           0
                           0 1 2 3 4 5 6 7
                          +-+-+-+-+-+-+-+-+
                          | Burst Quantum |
                          +-+-+-+-+-+-+-+-+

                          Figure 7: Burst Quantum

   Burst quantum with 8 bits represents burst sizes of up to 768 Kbytes
   (3 Kbytes * 2^8).  It should be noted that a single burst may span
   multiple MDUs or media streams.

A.2.6.  Sequence Number

   Sequence number is a counter that starts at arbitrary value,
   increases in value by 1 for each packet and wraps around after the
   largest number (2^16) represented in the field.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 18]
Internet-Draft           Media Header Extensions           February 2024

                  0                   1
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |       Sequence Number         |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 8: Sequence Number

   The sequence number is used by the wireless router to detect loss or
   out of order arrival of packets.

A.2.7.  Timestamp

   Timestamp filed contains the transmission time of the packet as
   defined in NTP short format [RFC5905].  The first 16 bits represent
   integer part in seconds, and the second 16 bits represent the
   fractional part of a second.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           (sec)               |          (fraction)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: Timestamp in NTP short format

   Jitter is the variation in delay from a mean delay in milliseconds
   measured over a number of packets received.  The resolution of the
   fractional part in [RFC5905] short format far exceeds a millisecond
   and is sufficient for calculating jitter at the wireless router.

A.3.  Configuring Obfuscated Codes

   Obfuscated codes should be configured between the CAP and CSP using a
   secure TLS channel prior to sending in UDP option in outer UDP
   encapsulation.  Obfuscated codes (OFC) are cryptographic random
   numbers (128 bit) generated by the application server in the CAP and
   associated to a set of sensitive application metadata.  The
   application server sends the OFC and associated sensitive metadata to
   the wireless router in CSP over a secure TLS channel.

   Sensitive metadata include start/end of MDU, relative priority/
   importance and delay tolerance.  An example text-based coding is
   shown below for readability, but binary object representations may be
   used in practice.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 19]
Internet-Draft           Media Header Extensions           February 2024

  {
    “marker”: [“start/end”, “middle”],
    “importance”: [“high”, “medium”, “low”],
    “delTolerance”: [“high”, “low”],

  {“name”: OFC-1,“obfuscated-code”: 0x2a7b6a58fcd0049a0330ea7746baf01,
     “marker” : “start/end” “importance”: “high”, “delTolerance”: “low”}
  {“name”: OFC-2, “obfuscated-code”: 0xfba7763eda0050a0041dc1246dafc20,
     “marker” : “middle”, “importance”: “high”, “delTolerance”: “low”}
  }

   The above shows a configuration of obfuscated codes OFC-1 and OFC-2
   with 'start/end' and 'middle' for high importance and low delay
   tolerance.  In practice, multiple OFC codes corresponding to the same
   metadata should be used on the wire to avoid the possibility of
   observing the frequency /pattern of codes.  For example, the
   application server may setup 5 OFC codes for the same set of
   metadata.  When the application server sends metadata, it can use a
   random mix of the OFCs such that an observer on path cannot use
   frequency analysis to determine a pattern.

   Obfuscated codes may similarly be used to identify/distinguish
   between different streams (e.g., QUIC for audio, video, etc. where
   stream headers are not observable by the UPF).  An example text
   encoding for this is shown below.

    {
      “streams”: [“A”, “B”],
      “importance”: [“high”, “low”],

    {“name”: OFC-11,“obfuscated-code”:0x2a7b6a58fcd0049a0330ea7746baf01,
        “stream” : “A” “importance”: “high”}
    {“name”: OFC-12,“obfuscated-code”:0xfba7763eda0050a0041dc1246dafc20,
        “stream” : “B”, “importance”: “low” }
    }

   The application server should initiate re-configuration of OFCs on a
   regular basis.  Frequency of re-configuration needs to be considered
   further.

   Other metadata including burst size, sequence number and timestamp do
   not reveal any additional information about the media payload are not
   sensitive.  A burst of packets can be observed on path and providing
   this information does not add anything that was not already
   observable.  This field has value for a wireless network to manage
   radio resources if provided at the start of the burst of packets.
   Sequence number and timestamp also do not reveal additional
   information that was not otherwise available.  However, all the of

Kaippallimalil, et al.   Expires 17 August 2024                [Page 20]
Internet-Draft           Media Header Extensions           February 2024

   the parameters here and the OFCs MUST be integrity protected to
   detect modification on path.  Transport of OFC and related metadata
   is in Appendix A.4.2.

A.4.  Transport of Metadata

   Metadata is sent from the server to the wireless router in each media
   packet and may contain information about a media frame (MDU) or media
   stream.  Since most if not all low latency media transport uses UDP,
   the transport of metadata uses one of two new UDP options defined
   based on [I-D.ietf-tsvwg-udp-options].  A message digest in AUTH UDP
   option is used with MED and OFC to allow the wireless router to
   detect any modification of metadata on path.  Media protocols (RTP,
   QUIC) are not fragmented and thus the MED or OFC UDP option with
   metadata is carried in each packet.  The media payload is limited in
   size to allow the addition of the MED and AUTH UDP options within the
   UDP packet and not exceed the MTU.

A.4.1.  MED UDP Option

   MED is a new UDP option that conforms to
   [I-D.ietf-tsvwg-udp-options].  It is a SAFE option as there is no
   alteration of UDP payload in any manner and should be assigned a
   value in the 0..191 range as per [I-D.ietf-tsvwg-udp-options].  The
   AUTH UDP option should be used to detect any modification of data in
   MED.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Kind=TBA1   |    Len=12     |      RES    |S| MDU-stream ctr|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Importance |Del| Burst Quantum |        Sequence Number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 10: MED UDP Option

   MED has a fixed length of 12.  There are a number of bits reserved
   for future use in the field RES.  Flag "S" denotes if the data that
   follows is for a media frame or a media stream.  The MDU-stream
   counter represents MDU (media frame) or stream counter that has the
   same value for an MDU/stream.  Importance and delay tolerance are
   used for both MDU and stream and described in Appendix A.2.3 and
   Appendix A.2.4.  Burst quantum, sequence number and timestamp are not
   directly tied to one MDU or a stream and are described in
   Appendix A.2.5, Appendix A.2.6 and Appendix A.2.7.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 21]
Internet-Draft           Media Header Extensions           February 2024

A.4.2.  OFC UDP Option

   OFC is a new UDP option that conforms to
   [I-D.ietf-tsvwg-udp-options].  It is a SAFE option as there is no
   alteration of UDP payload in any manner and should be assigned a
   value in the 0..191 range as per [I-D.ietf-tsvwg-udp-options].  The
   AUTH UDP option should be used to detect any modification of data in
   OFC.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Kind=TBA2   |     Len=16    |     Obfuscated Code (OFC)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         OFC (128 bit)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      OFC      | Burst Quantum |       Sequence Number         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 11: OFC UDP Option

   OFC has a fixed length of 16.  The obfuscated code that represents
   importance, delay tolerance and stream/MDU information is carried in
   a 128-bit OFC value described in Appendix A.3.  The OFC value may be
   configured to be information on a media frame/MDU or stream and only
   known to the server and wireless router.  Importance and delay
   tolerance are used for both MDU and stream and described in
   Appendix A.2.3 and Appendix A.2.4.  Burst quantum, sequence number
   and timestamp are not directly tied to one MDU or a stream and are
   described in Appendix A.2.5, Appendix A.2.6 and Appendix A.2.7.

A.5.  IANA Considerations

   Note: this is an Appendix, but added here for discussion on the
   solution.

   IANA request to assign new kind from UDP option registry to be set by
   IANA for [I-D.ietf-tsvwg-udp-options].

      Kind    Length       Meaning
      -----------------------------------------------------
      TBA1      12         Media Metadata (MED)
      TBA2      16         Obfuscated Metadata (OFC)

Kaippallimalil, et al.   Expires 17 August 2024                [Page 22]
Internet-Draft           Media Header Extensions           February 2024

A.6.  Security Considerations

   Note: this is an Appendix, but added here for discussion on the
   solution.

   The metadata itself should ensure that no additional information
   about either the content or the user of the content is revealed.  And
   if the metadata is modified on path, it should be possible to detect
   at the wireless router.

   The size of a burst of packets, sequence and time information can be
   observed or inferred by entities on path between server and wireless
   router.  Hence, the metadata in Burst Quantum, Sequence Number and
   Timestamp in both MED and OFC do not reveal information that is not
   otherwise possible to.  However, these and all other parameter values
   in MED and OFC are vulnerable to modification on path.  Therefore,
   all metadata in MED and OFC are protected by UDP option AUTH.

   Encrypted media payloads along with temporary IP addresses between a
   server and user (client) provide a measure of privacy for the content
   and the identity of the user.  It should however be noted that media
   flows encrypted using RTP transports can exhibit a pattern of bursts
   that amounts to a signature and is vulnerable to frequency analysis.
   Vulnerability to frequency analysis is inherent in media sent by the
   server unless scheduled or multiplexed independently to each user/
   recipient.  The security aspects of the media payload/ transport are
   not in the scope of these requirements and is described here only to
   provide context for metadata privacy.

   Metadata sent using MED UDP option is vulnerable to frequency
   analysis to infer the contents of media payload.  This is not problem
   with media transports based on RTP as there is a distinct pattern
   that can be observed and thus, MED does not reveal any further
   information in such cases.  When using a media transport uses
   protocols like QUIC and also dynamically schedules media streams in
   such a way that the composition is unpredictable, they are not
   vulnerable to frequency analysis on path.  MED can be used when the
   CAP, CSP and the IP transit network connecting them are trusted and
   managed to ensure that the traffic is secure from unauthorized
   monitoring.

Kaippallimalil, et al.   Expires 17 August 2024                [Page 23]
Internet-Draft           Media Header Extensions           February 2024

   The OFC UDP option can represent a single set of metadata using
   multiple codes.  This makes it unpredictable for any observer on the
   wire to derive what a sequence of codes sent per packet represents as
   there is no meaningful pattern when observed on the wire.  The OFC
   codes themselves are configured between server and wireless router in
   a secure manner using TLS.  OFCs can be used when there are lower
   levels of trust against unauthorized monitoring across the CAP, CSP
   or IP transit network in between.

Authors' Addresses

   John Kaippallimalil
   Futurewei
   Email: john.kaippallimalil@futurewei.com

   Sri Gundavelli
   Cisco
   Email: sgundave@cisco.com

   Spencer Dawkins
   Tencent America LLC
   Email: spencerdawkins.ietf@gmail.com

Kaippallimalil, et al.   Expires 17 August 2024                [Page 24]