Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors John Kaippallimalil , Sri Gundavelli
Last updated 2023-02-20
Replaces draft-kaippallimalil-media-hdr-wireless-networks
RFC stream (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-01
TSVWG WG                                               J. Kaippallimalil
Internet-Draft                                                 Futurewei
Intended status: Standards Track                           S. Gundavelli
Expires: 24 August 2023                                            Cisco
                                                        20 February 2023

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

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 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 and QoS in general 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 importance of the packet, burst length and time budget to be
   conveyed by the media application in a new UDP option.  The metadata
   in the UDP option is 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.

   This draft defines media metadata, a new UDP option to carry this
   metadata and the operational aspects for using it between a UDP
   source and a on-path wireless 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 & GundavelExpires 24 August 2023                 [Page 1]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   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 24 August 2023.

Copyright Notice

   Copyright (c) 2023 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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Media Metadata  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Design Criteria . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Metadata Parameters . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Profile . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.2.  Timestamp . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.3.  Media Data Unit Sequence  . . . . . . . . . . . . . .   9
       4.2.4.  Packet Counter  . . . . . . . . . . . . . . . . . . .  10
       4.2.5.  Importance  . . . . . . . . . . . . . . . . . . . . .  10
       4.2.6.  Data Burst  . . . . . . . . . . . . . . . . . . . . .  11
       4.2.7.  Delay Budget  . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Metadata Handling . . . . . . . . . . . . . . . . . . . .  12
   5.  Metadata Transport  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Common Deployments  . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Data Center Deployment  . . . . . . . . . . . . . . . . .  14
     6.2.  Security Gateways . . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 2]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

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 when a combination of high
   throughput and low latency are required.  Media packets on the other
   hand typically demand both high throughput and low latency.  The
   application is able to adapt, but when the feedback signal (i.e., via
   end-to-end congestion signaling or application level feedback) is of
   low resolution and frequency 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 has studied enhancements in the wireless network in
   [TR.23.700-60-3GPP] for such media applications that demand high
   bandwidth and low latency.  Some of the recommendations include
   providing the wireless network with information on groups of media
   packets that should be handled similarly (e.g., packets of a video
   I-frame), the importance of a media packets and others that allow the
   wireless network to schedule and forward packets more optimally.

   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.  This is also inline with the recommendations in [RFC8558]
   that discuss explicit signals to on-path network elements.  Section 4
   proposes a set of metadata that the wireless network can use to
   optimize media packet forwarding in the wireless network.

   Metadata inserted by a media application is transported across
   trusted networks between the application server that inserts metadata
   and the on-path wireless entity that uses it.  The transport is
   designed to allow carrying metadata for a range of media transports
   including SRTP [RFC3711] and HTTP/3 media over QUIC.  A new UDP

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 3]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   option [I-D.ietf-tsvwg-udp-options] is proposed here to carry the
   metadata.  The trade-off in terms of lookup efficiency, protocol
   overhead, the constraints for transporting metadata across trusted
   networks and other related aspects are discussed in Section 3.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Terminology

   The following terms is used in this document:

   *  Media Data Unit (MDU) - a set of one or more IP packets carrying a
      media payload that should be treated as unit in the wireless
      network.  For example, packets of an MDU may be of a low priority
      and all packets may be dropped in case of extreme congestion.  In
      protocols like RTP, the payload may consist of data of one media
      type (e.g., a video I-frame) and in protocols like HTTP/3 that
      carry multiple streams, each stream in the packet can potentially
      carry a payload of different media types.  In either case, the
      application should classify the MDU that a packet belongs to and
      in turn the network applies policies that treat the set of packets
      of an MDU as a unit.

   *  Importance - The importance of a packet (or group of packets
      belonging to an MDU) identify the priority of the packet(s),
      dependency between packet(s) of an MDU to another (e.g., packets
      of a video P-frame depend on an I-frame) and delivery preferences
      when packet(s) are delayed due to congestion or temporary lack of
      wireless resources.  The application marks importance (and other
      metadata) and the wireless network interprets the marking as
      preferences when handling these media packets under reduced
      wireless capacity.  If an application marks all packets with the
      same priority, the result would be random packet drop in the
      wireless network in the presence of extreme congestion.

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 4]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

3.  Architecture

   Section 1 has outlined the the issue around changes in link capacity
   in a wireless network changes and the need for additional information
   to handle such flows in the wireless network.  This section provides
   an end-to-end view of what the wireless network needs to optimize its
   resource handling and the actions of clients, servers and entities in
   the network to facilitate it.

         UDP encrypted payload     UDP encrypted payload + metadata
         +-------------------+     +=========================+
        /                     \   /         _____             \
       /         _____         \ /         (     )             \
      /         (     )     +---V----+    (        )            \
 +---V----+    (Wireless)   |Wireless|   (    IP    )       +----o-----+
 | Client +---( Network  )--+  Node  +--(   Network  )------+  Server  |
 +--------+    (        )   +--------+   (          )       +----------+
 (UDP dest)     (_____)                   (       )         (UDP source)
                                           (_____)

                  Wireless Network                        Appl Network
             |------------------------|                 |--------------|

      Figure 1: Media Metadata in Application and Wireless network

   Figure 1 shows an end-to-end view where a packet containing a media
   payload from a server (e.g., a media server or relay) is sent to a
   client (i.e., a wireless end point).  The general assumption here is
   that the server and on-path wireless node that serves the wireless
   end point in Figure 1 are in two networks.  These two networks share
   a trust relationship that allows entities in these networks to
   exchange media metadata.  The relationship also limits the exposure
   of the media metadata to authorized entities within the two networks.
   A trusted domain (e.g., as outlined in [RFC8799]) associated to the
   wireless and application networks with a public key and trust anchors
   within each network have the ability to perform operations to
   authorize, enroll, and manage nodes with specific policy and roles
   (i.e., server, wireless node, gateways) for managing media metadata
   handling in a secure manner.  When the application (server, UDP
   source) and wireless network are not directly connected, a secure
   overlay network with encryption MUST be used between the two domains.

   The server and client in Figure 1 have signalled to setup the media
   session (e.g., using SDP, HTTP) prior to sending media packets.  The
   UDP source (e.g., an Application Server) is responsible for inserting

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 5]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   relevant metadata based on the media content of the packet and using
   the metadata format specified in Section 4.  The metadata in the UDP
   option is delivered to the wireless node (e.g., a 3GPP UPF) that
   classifies it using the metadata in the packet along with other
   network policies.  The metadata and its transport are designed to be
   efficient in processing and byte overhead per packet.  The metadata
   is expected to work with any UDP media including RTP, SRTP and
   HTTP/3.  Metadata parameters are encoded in binary format for compact
   representation.  Details are in Section 4.

   The UDP option and metadata defined in this specification must only
   be exchanged between entities that are trusted.  The server (UDP
   source) and Wireless Node (access router in wireless network) are
   configured with data that allow establishment of trust between the
   entities and the network(s) in between prior to the exchange of
   metadata using the UDP option defined in this specification.  When
   there are insecure network segments in between, all packets that
   carry the metadata in the MED UDP option must be secured with
   encryption between these segments (e.g., secure GRE/VXLAN tunnel) or
   at a flow level (e.g., with MASQUE proxies).  Section 6 describes a
   few common deployments.

   The application server (server in Figure 1) is responsible for
   inserting the metadata in the UDP option.  The application server
   determines the importance and other metadata parameters based on the
   type of media encoded as well other information (e.g., configured
   information on destination wireless network, live feedback from the
   session).  The application encrypts the payload (i.e., media content)
   in the UDP packet and adds the MED UDP option to be processed in the
   wireless network.  Entities on-path do not process the UDP option,
   but security gateways or other network entities at the boundary of a
   trust domain may remove the option if there is an untrusted network
   segment on-path.  The wireless node receives UDP packet, inspects the
   metadata in the UDP option and applies local policies to the metadata
   to derive optimal scheduling and forwarding on the wireless path.
   The wireless node does not examine the content of the packet which
   may use various encrypted application transports like SRTP cryptex,
   HTTP/3 and may have variable number of media streams.

4.  Media Metadata

   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, resiliency (i.e., the ability to
   recover from loss) or even subjective importance (e.g., a loss of a
   video base layer I-frame packets is more significant than enhanced

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 6]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   layer P-frame).  Media encoding is evolving continually and modern
   codecs use complex prediction structures and make various dynamic
   decisions in the encoding process.  However, it is expected that
   there are differences in priority, delay and acceptable loss across
   sets of packets.  This is information that the wireless network can
   use to provide a better 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 is for a
   minimal set of metadata that is useful for optimizing handling of
   media packets.  The end-to-end aspects and metadata parameters are
   described below.

4.1.  Design Criteria

   A media application that uses this specification provides a set of
   metadata about the media packet that an authorized wireless network
   can inspect and use to optimize handling during adverse radio
   conditions.  Metadata for media packets are carried in a new UDP
   option discussed further in Section 5.

   Metadata defined in Section 4.2 is broad enough to be applied
   regardless of whether the application uses RTP, HTTP or another
   application transport protocol.

   The media application(server, or UDP source) is responsible for and
   retains control over the metadata that is inserted at the UDP source.
   The media application only inserts metadata if the destination
   (wireless end point) is a device in a trusted wireless network.  For
   example, a range of IP addresses that belong to the trusted wireless
   network.  The wireless network verifies that a packet with MED UDP
   option metadata has originated from a trusted server.  The wireless
   network that inspects metadata may defer or drop packets to optimize
   the use of radio resources.  The application may receive out of band
   feedback on the quality and other statistics of the data received at
   the UDP destination (e.g., RTCP receiver report).  The application
   may use heuristics or other algorithms on the feedback, explicit
   network congestion information, encoding characteristics of the media
   or other aspects of the data to obtain the desired handling in the
   wireless network.  Details of the mechanisms an application uses is
   not in the scope of this document.  The feedback provided allows the
   application server (or UDP sender) to remain in control and determine
   if there is any potential malicious or incoherent handling of media
   packets.  In such cases, the the application server (or UDP sender)
   can revert to marking all packets with the same level of importance.

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 7]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   The on-path wireless network entity that inspects metadata does not
   rely on packets arriving in order.  The metadata itself should
   provide sufficient information and the network entity should factor
   in these assumptions when calculating jitter and burst length using
   the metadata in each packet.  For example jitter may be calculated as
   a moving average across multiple packets and burst length should
   compensate for potential out-of-order packet arrivals especially
   towards the tail end of a burst.

   Metadata is transported in a new UDP option, MED, defined in
   Section 5.  The metadata in MED UDP option is carried in each packet
   that the application server (or UDP source) inserts.  Thus, the
   wireless entity keeps some state information to use the metadata.
   For example, a sequence counter is used to track the set of packets
   that belong to a media data unit (MDU), and a series of timestamps
   may be used to derive jitter.  The different metadata parameters are
   described below in Section 4.2.

   This specification describes one set of metadata described as a
   profile.  A Profile field makes this specification extendable to
   future specifications that describe a new metadata profile.

4.2.  Metadata Parameters

   The media application provides a set of metadata about the content of
   the packet and the wireless network inspects the metadata and uses to
   optimize handling during adverse radio conditions.  Some information
   that is useful to wireless networks include the importance of a
   packet (or a group of packets), the number of packets in a burst,
   timestamps and acceptable end-to-end latency of the packet.
   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
   stored in advance, it may be able to tolerate some additional delay
   over a real-time video encoding carried in another stream.  Only the
   media application is able to provide such information since even
   inspecting a clear media header (e.g., RTP packet carrying an I-frame
   fragment) does not provide the on-path network entity with sufficient
   information as whether that represents live media, the length of a
   data burst or the actual delay budget where the packet is useful for
   decoding.

   The parameters below identify a minimum set that an on-path network
   entity can use for optimizing the use of wireless network resources.

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 8]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

4.2.1.  Profile

   This parameter allows for more metadata profiles to be carried by the
   MED UDP option.  This specification only defines one profile.

              0
              0 1 2 3 4
             +-+-+-+-+-+
             | Profile |
             +-+-+-+-+-+

          Value      Meaning
          -----------------------------------------------------
            0        RESERVED
            1        Basic - defined in this specification
            2-31     Unassigned (assignable by IANA)

   Specifications may define a new metadata format in future using one
   of the unassigned values.

4.2.2.  Timestamp

   Timestamp contains the wallclock time (absolute date and time) of
   transmission of the packet and is represented in a compact format
   where the first 16 bits represent seconds relative to 0h UTC on 1
   January 1900, 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A pair of timestamps S2 and S1 represent a time interval between them
   of (S2 - S1) that have sequential Packet counter values.  The
   transmission time contained in the field may be used for network
   jitter calculations.

4.2.3.  Media Data Unit Sequence

   The Media Data Unit (MDU) sequence is a cyclical counter that has the
   same value for a set of packets identified by an application to be
   treated as a unit (i.e., an MDU), and is incremented for the next
   MDU.

Kaippallimalil & GundavelExpires 24 August 2023                 [Page 9]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

              0
              0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             | MDU Sequence  |
             +-+-+-+-+-+-+-+-+

   The wireless network uses this field to provide consistent treatment
   to the set of packets that belong to the same MDU.  In some cases,
   based on the priority and tolerance to delay and loss, the wireless
   network may delay or drop the sequence of packets that has the same
   MDU sequence value.  An MDU sequence of 8-bits means that there can
   be upto 256 (2^8) concurrent MDU sequences for a UDP source/
   destination pair that a wireless network can distinguish.

   The MDU sequence value is not itself associated to any set of media
   properties.  These media properties are defined in Importance, burst
   length and delay in the sections that follow.

4.2.4.  Packet Counter

   This parameter provides a counter starting at "0" that is incremented
   for each subsequent packet belonging to a Media Data Unit (MDU).

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

   The delay between subsequent packets of an MDU may be averaged or
   otherwise used to extrapolate jitter in the arrival stream at the
   wireless node.

4.2.5.  Importance

   Importance represents the media characteristics of the set of packets
   that that form a media data unit (MDU) relative to the
   characteristics of another MDU.  The characteristics represented in
   importance are the priority level, the ability to tolerate delay and
   transmission errors.

Kaippallimalil & GundavelExpires 24 August 2023                [Page 10]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

            0
            0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+
           | L |  D  |  P  |
           +-+-+-+-+-+-+-+-+

         Value      Meaning
        -----------------------------------------------------
           L        Delay Tolerance
                      00   limited value if delayed
                      01   should be forwarded even if delayed
           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
                     001   high priority
                     010   medium priority
                     100   low priority

   The application determines the priority of a packet in terms of how
   critical the loss of packets of an MDU is for a destination/decoding
   end.  Some media frames may be extremely important but not as
   sensitive to delay, others may be important and should be delivered
   even past a delay deadline.  There are various other factors such as
   packets with medium or lower priority and varying tolerance for delay
   that need to be considered.

   The dependency flags indicate whether the packet is independent or
   dependent on packets of other MDUs.  TBD - specification/behavior of
   the different values of priority.

4.2.6.  Data Burst

   The data burst field represents the number of byptes of data in a
   continuous burst of packets.  This may be the result of a large
   amount of media encoded at a particular time.  In many cases, the
   distribution of packets tend to be heavy tailed and this information,
   if available to the wireless network at the beginning of the burst,
   is useful to let the wireless network know so that it can plan for
   radio resources in advance.  In RTP streams, a burst may for example
   represent the number of bytes to send in a video I-frame.  However,
   in more complex encodings where the media in a packet belongs to
   multiple streams (e.g., AR/VR), the application should determine the
   length of a burst of data.

Kaippallimalil & GundavelExpires 24 August 2023                [Page 11]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Data Burst                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the value is set to "zero", it indicates that the application does
   not provide the size of the data burst.  All other values indicate
   the actual size of the data burst in bytes upto a maximum of 2^32
   bytes.  The wireless node keeps track of the number of bytes in each
   packet payload to determine the total number of bytes in a burst.

4.2.7.  Delay Budget

   The delay budget represents an upper bound in milliseconds between
   the reception of the first packet of the MDU to the last packet of
   the MDU.

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

   The delay budget along with data burst and importance (priority) is
   used to convey to the wireless network in advance the duration of
   time over which the burst of packets is sent.  This can allow the
   wireless scheduler to plan for the appropriate level of resources.

4.3.  Metadata Handling

   Metadata in this specification consists of the set of parameters in
   Section 4.2 and always uses Profile value of "1".

   The application server (UDP source) inserts the metadata into each
   packet.  The application server should only prepare metadata in UDP
   MED option if the UDP destination belongs to a wireless network that
   has a trust relationship with the application network.  Importance,
   data burst and delay budget parameters are the same for all packets
   of an MDU (identified by an MDU sequence value for the UDP source/
   destination).  The timestamp indicates the sending time of each
   packet while the packet counter is incremented for each packet in an
   MDU.

Kaippallimalil & GundavelExpires 24 August 2023                [Page 12]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   The wireless node that receives metadata in the UDP MED option should
   verify that it orinated from an application network with which it has
   a trust relationship.  The metadata is used to prioritize, defer or
   drop packets of an MDU when radio resources are limited.

5.  Metadata Transport

   Transport of metadata between the application and wireless network
   may be based on one of several protocol options but it would be
   preferable to have one mechanism (or limited number) so that wireless
   network entities do not have to support a large number of options.
   Some considerations include the ease with which an application can
   encode the metadata in a transport header, compactness and efficiency
   for lookup in the wireless network as this is applied per packet, and
   the security of the metadata itself (not unique to wireless
   networks).  In this specification, the media metadata is transported
   in UDP options.  UDP transport of metadata is efficient and
   applicable to not only HTTP/3 media but also RTP/SRTP for any further
   extensions related to wireless networks.

   A new UDP option, MED, that conforms to [I-D.ietf-tsvwg-udp-options]
   is defined to carry media metadata.  Figure 2 shows the parameters in
   the MED UDP option.  The Kind value for this option is (TBD - IANA
   assigned).  The MED option is a SAFE option as it does not alter the
   UDP data payload in any manner and should therefore be assigned a
   value in the 0..191 range as defined in [I-D.ietf-tsvwg-udp-options].
   The length of this option can be variable since another specification
   can define a new media "Profile" of a different length.

        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=17     | RES | Profile |  Importance   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | MDU Sequence  |              Packet Counter                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Data Burst                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Delay      |
       +-+-+-+-+-+-+-+-+

               Figure 2: MED UDP Option in Long Format

Kaippallimalil & GundavelExpires 24 August 2023                [Page 13]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   The MED UDP option in this specification has a size of 17 bytes.  In
   this specification, the Profile option MUST be set to "1".  Following
   the length field, 3 bits are left reserved (RES) for future use.  The
   MDU sequence indicates the set of media data unit packets of the UDP/
   IP datagram 5-tuple).  The MDU sequence value should be the same for
   all packets that form a media data unit (MDU) Other UDP/IP datagrams
   (e.g., from the same server to another client) that have the same
   value of MDU sequence represents a different MDU set.  The Importance
   of a packet includes its priority relative to other MDUs of the same
   UDP/IP datagram (5-tuple).  The Timestamp value in this option
   represents the transmission time of the packet and along with Packet
   counter may be used to derive latency and jitter information.  For a
   media flow/sequence identified by IP 5-tuple, the MDU sequence is
   incremented for every subsequent MDU.  The Packet counter represents
   a sequence of packets of an MDU and may be used along with timestamps
   to derive jitter.  The wireless node does not attempt to sequence
   packets arriving out of order using the Packet counter.  The Data
   burst when provided indicates the number of bytes of the MDU and this
   value remains the same for all packets of the MDU.  The Delay field
   conveys the upper bound in milliseconds between the reception of the
   first packet of the MDU to the last packet of the MDU.  All packets
   of an MDU have the same value of Delay.

   The UDP source (application server) MUST NOT add the UDP MED option
   if the UDP destination (wireless client) does not belong to a
   wireless network that has a trust relationship with the application
   network.  The wireless network MUST NOT use metadata in the UDP MED
   option of the UDP source (application server) does not belong to an
   application network that has a trust relationship with it.  The
   wireless network MUST remove the UDP MED option before forwarding the
   packet to the wireless node regardless of whether it originated from
   a trusted or untrusted network.

   A security gateway at the boundary of an application network or
   wireless network that share a trust relationship should inspect the
   UDP MED option to ensure that the origin/destination network comply
   with the policies of the domain.

6.  Common Deployments

   This section provides a few examples of common deployments and the
   use of the MED UDP option to carry media metadata.

6.1.  Data Center Deployment

   In this deployment scenario, the UDP source (i.e., App Server) and
   the wireless network entity (i.e., Wireless Node) are within the same
   Data Center and within a secure network.

Kaippallimalil & GundavelExpires 24 August 2023                [Page 14]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

               Wireless Network Provider               App Provider
            |----------------------------------|     |---------------|
               ______              +--------------------------------+
              (      )             |  +--------+       +----------+ |
   +------+  (Wireless)            |  |Wireless|       |   App    | |
   |client/---------------------------/        /=======/  Server  | |
   +------+  (Network )            |  |  Node  |       +----------+ |
              (______)             |  +--------+                    |
                                   +--------------------------------+
                                                Data Center

                                  /======/ UDP Packet with MED option
                                  /------/ UDP Packet (no MED option)

            Figure 3: Server and Wireless entity in Data Center

   The UDP MED option is inserted by the Application Server and
   forwarded.  The network in between is within the boundaries of the
   trust domain.  The Wireless Node processes the metadata in the MED
   UDP option and before forwarding the packet to the client (wireless
   end point), the MED UDP option is removed.

6.2.  Security Gateways

   In this deployment scenario, the UDP sender (i.e, App Server) and the
   wireless network entity (i.e., Wireless Node) have a trust
   relationship between them and security gateways are used to encrypt
   all traffic traversing an insecure network segment in between.

               Wireless Network Provider            Application Provider
            |------------------------------|        |------------------|
               ______
              (      )   +--------+   +---+         +---+    +--------+
   +------+  (Wireless)  |Wireless|   |Sec|_________|Sec|    |  App   |
   |client/--------------/        /===+GW O____+____O GW+====/ Server |
   +------+  (Network )  |  Node  |   |   |    |    |   |    +--------+
              (______)   +--------+   +---+    |    +---+
                                               V
                                         Secure Tunnel

                                    /======/ UDP Packet with MED option
                                    /------/ UDP Packet (no MED option)

      Figure 4: Security Gateways between Server and Wireless network

Kaippallimalil & GundavelExpires 24 August 2023                [Page 15]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   The UDP MED option is sent between App Server and Wireless Node.  The
   Wireless Node removes the MED UDP option before forwarding the packet
   onwards.

7.  Acknowledgements

   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.

8.  IANA Considerations

   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      17         Media Metadata (MED)

9.  Security Considerations

   Metadata in the UDP option MED must only be exchanged between
   entities that have a trust relationship that permits sending/
   receiving this UDP option.

   Metadata in the MED UDP option MUST NOT be sent to a wireless network
   that does not have a trust relationship with the application network
   (UDP source).  A wireless network that receives a MED UDP option MUST
   verify that the origin of the metadata is from a trusted network.
   After processing the MED option, the wireless network node MUST
   delete the option before forwarding the packet.

   If the application network that sends the media packet with MED UDP
   option and the wireless network that receives the UDP packet/MED
   option are separated by an untrusted network, the traffic must be
   encrypted across the untrusted network segment.  Security gateways at
   the boundary of the origin /destination networks SHOULD inspect to
   verify that the MED UDP option to verify that the origin or
   destination of the packet with UDP MED option are across the two
   trusted networks.

10.  References

10.1.  Normative References

Kaippallimalil & GundavelExpires 24 August 2023                [Page 16]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

   [I-D.ietf-tsvwg-udp-options]
              Touch, J. D., "Transport Options for UDP", Work in
              Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-19,
              27 December 2022, <https://www.ietf.org/archive/id/draft-
              ietf-tsvwg-udp-options-19.txt>.

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

10.2.  Informative References

   [draft-ietf-avtcore-cryptex-08]
              IETF, "Encrypting RTP Header Extensions and Contributing
              Sources", August 2022.

   [I-D.iab-path-signals-collaboration]
              Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
              "Considerations on Application - Network Collaboration
              Using Path Signals", Work in Progress, Internet-Draft,
              draft-iab-path-signals-collaboration-03, 3 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-iab-path-
              signals-collaboration-03>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <https://www.rfc-editor.org/info/rfc3711>.

   [RFC8558]  Hardie, T., Ed., "Transport Protocol Path Signals",
              RFC 8558, DOI 10.17487/RFC8558, April 2019,
              <https://www.rfc-editor.org/info/rfc8558>.

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

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

Kaippallimalil & GundavelExpires 24 August 2023                [Page 17]
Internet-Draft  Media Header Extension Wireless Networks   February 2023

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 & GundavelExpires 24 August 2023                [Page 18]