MoQ relays for Support of High-Throughput Low-Latency Traffic in 5G
draft-defoy-moq-relay-network-handling-02

MOQ                                                            X. de Foy
Internet-Draft                                              InterDigital
Intended status: Standards Track                              R. Krishna
Expires: 10 April 2025                                                  
                                                                T. Jiang
                                                            China Mobile
                                                          7 October 2024

  MoQ relays for Support of High-Throughput Low-Latency Traffic in 5G
               draft-defoy-moq-relay-network-handling-02

Abstract

   This document describes a mechanism to convey information about media
   frames.  The information is used for specific handling in functions
   such as error recovery and congestion handling.  These functions can
   be critical to improve energy efficiency and network capacity in some
   (especially wireless) networks.  Due to end-to-end encryption, MoQ
   relays are expected to extract the metadata required by these
   functions.  This document aims to enable a level of wireless network
   support for MoQ equivalent to what is possible for RTP.

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 10 April 2025.

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.

de Foy, et al.            Expires 10 April 2025                 [Page 1]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Techniques used by Wireless Networks for XR Traffic
           Handling  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Identifying XR Metadata in RTP Media Flows  . . . . . . .   3
     1.3.  Identifying XR Metadata in MOQ flows  . . . . . . . . . .   4
   2.  XR Metadata for 5G  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  XR Metadata for PDU Sets  . . . . . . . . . . . . . . . .   4
     2.2.  Applying XR Metadata to MOQT  . . . . . . . . . . . . . .   5
       2.2.1.  Signalling of XR Metadata Support . . . . . . . . . .   6
       2.2.2.  XR Metadata in MOQT Datagrams . . . . . . . . . . . .   6
       2.2.3.  XR Metadata in MOQT Streams . . . . . . . . . . . . .   7
   3.  Traffic Handling of High-Throughput Low-Latency Traffic . . .   8
     3.1.  MoQ relay Behavior  . . . . . . . . . . . . . . . . . . .   8
     3.2.  Endpoint Behavior . . . . . . . . . . . . . . . . . . . .   8
   4.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  XR RTP Header Extension for XR Traffic Handling in 5G
           Networks  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  Release 18 XR Metadata  . . . . . . . . . . . . . . . . .  10
     A.2.  Release 19 XR Metadata  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Wireless networks can be a challenging environment for applications
   with high-throughput and low latency requirements, such as video
   conferencing and Extended Reality (XR, presented for example in
   [I-D.draft-ietf-mops-ar-use-case]).  Wireless networks implement
   techniques to improve network capacity and energy efficiency, as well
   as reduce the impact of packet losses on users' quality of experience
   (Section 1.1).  An extension to the RTP protocol [TS26.522] has been
   defined, which enables metadata associated with application data
   units to be identified at the ingress point of the wireless network
   (Section 1.2).  To enable a similar operation with the MoQ protocol
   [I-D.draft-ietf-moq-transport], this document describes how a MoQ
   relay can be used at the ingress point of the wireless network
   (Section 1.3).

de Foy, et al.            Expires 10 April 2025                 [Page 2]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

   The rest of this document is structured as follows:

   *  Section 2 describes XR metadata for MoQ, based on what is
      currently defined by 3GPP for RTP.

   *  Section 3 describes the behavior of the MoQ relay and of MOQ
      endpoints.

   *  Section 5 describes applicable security considerations.

1.1.  Techniques used by Wireless Networks for XR Traffic Handling

   The network can handle groups of packets based on how critical they
   are to the user's experience.  Some groups of data packets hold
   application data units that are handled (e.g., decoded) together by
   the application. 3GPP defines the term "PDU set" to identify these
   groups of data packets carrying the payload of an application data
   unit [TS23.501], which can correspond to the data packets of an
   application layer data unit.  The handling of application data units
   by the application can depend on other application data units (e.g.,
   in the case of decoding dependency).  The wireless network performs
   differentiated handling of groups of data packets.  For example, it
   prioritizes some groups over others in case of congestion.  In
   congestion situations, the network can also selectively drop data
   packets that depend on an already lost data packets.  Furthermore,
   the network can limit the amount of time that the radio needs to stay
   awake to transmit and receive data.  To achieve this this, the
   scheduler can use information on the size and periodicity of traffic,
   as well as delay budget and maximum tolerable jitter specific to the
   application.

1.2.  Identifying XR Metadata in RTP Media Flows

   To perform differentiated handling of PDU sets, a network node
   (typically a User Plane Function, UPF) at the ingress point of a
   wireless network identifies PDU set metadata from a downlink media
   flow. 3GPP has developed an RTP header extension for XR traffic for
   this purpose (see Appendix A for details).  When receiving a downlink
   packet, the UPF reads the XR metadata fields from the RTP header
   extension and transmits them to the RAN node in the GTP header that
   encapsulates the packet.  The RAN node uses the XR metadata
   information to implement the differentiated handling described in
   Section 1.1.

de Foy, et al.            Expires 10 April 2025                 [Page 3]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

1.3.  Identifying XR Metadata in MOQ flows

   For XR media traffic transported over the MOQ protocol, the UPF
   cannot access XR metadata unless it is exposed to the UPF in some
   fashion.  This document describes how the UPF can act as, or
   communicate with, a MoQ relay to obtain XR metadata associated with
   media data.  To enable this behavior, it is also necessary for the
   media sender to identify application data units that correspond to
   different desired traffic handling (e.g., different layers within a
   media frame), and provide associated metadata.  Figure 1 describes a
   UPF with a MoQ relay functionality, identifying XR metadata and
   transmitting it to access nodes, for example, for a media stream sent
   by B towards A and C.  For privacy and security, it is desirable that
   the MoQ relay, which can be operated by a network or service
   operator, does not have access to media data.  For interoperability,
   it is also desirable for these mechanisms to not be codec specific.

     +---+  +-----------+            +-----------+
     | A |<-|Access Node|------------|           |
     +---+  |           |<-metadata--|           |            +---+
            +-----------+            |    UPF    |<--data+md--| B |
                                     | MoQ relay |            +---+
            +-----------+            |           |
     +---+  |           |<-metadata--|           |
     | C |<-|Access Node|------------|           |
     +---+  +-----------+            +-----------+

    Figure 1: XR Traffic Handling by Access Networks using a MoQ relay.

2.  XR Metadata for 5G

2.1.  XR Metadata for PDU Sets

   XR metadata applies to IP packets from the 5G system standpoint.
   Some metadata is the same for a group of IP packets (the PDU set),
   while some metadata varies per IP packet within the PDU set.  Some
   metadata relates to a data burst, which may consist of one or more
   PDU sets sent together as one burst of data.

   3GPP defines metadata used for XR traffic handling when using RTP:

   *  In the 3GPP release 18 (RTP header extension for PDU set marking,
      [TS26.522])

      -  The _PDU Set Importance_ (*PSI*, 4 bits) is the importance of
         this PDU Set compared to other PDU Sets within the same
         Multimedia Session.

de Foy, et al.            Expires 10 April 2025                 [Page 4]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

      -  The _end PDU of PDU set_ (*E*, 1 bit) indicates the last PDU of
         the PDU set.

      -  The _end of data burst_ (*D*, 1 bit) indicates the last PDU of
         a data burst.

      -  The _PDU set sequence number_ (*PSSN*, 10 bits) identifies the
         PDU set.  The PSSN is incremented monotonically by 1 for each
         subsequent PDU set.

      -  The _PDU Sequence Number within a PDU Set_ (*PSN*, 6 bits)
         identifies a PDU with the PDU set, starting from 0 and
         incremented monotonically for every PDU in the PDU set in the
         order of transmission from the sender.

      -  The _PDU set size_ (*PSSize*, 24 bits) is an optional field
         which indicates the total size, in bytes, of all PDUs of the
         PDU Set (including IP header and IP payload).

      -  The _number of PDUs in the PDU Set_ (*NPDS*, 16 bits) is an
         optional field which indicates the number of PDUs in the same
         PDU set.

   *  In the 3GPP release 19 (work in progress, in normative stage based
      on the conclusion of [TR23.700-70])

      -  The _Burst Size_ (*BSize*) describes the size of a burst of
         traffic, which includes one or more PDU sets.

      -  The _Time to Next Burst_ (*TTNB*) describes the time between
         the end of the present burst and the beginning of the next
         burst.

   The optional header extension fields are included subjects to an SDP
   signaling offer/answer negotiation.

2.2.  Applying XR Metadata to MOQT

   In MOQT, XR metadata is transmitted in object headers.  This document
   describes XR metadata in the MOQT protocol, as needed for Release 18
   and 19 of 3GPP.

   _NOTE: a MOQT extension mechanism is currently being defined in
   https://github.com/moq-wg/moq-transport/pull/502/files
   (https://github.com/moq-wg/moq-transport/pull/502/files).  This
   document follows this mechanism and might need be updated to use the
   final mechanism, once published._

de Foy, et al.            Expires 10 April 2025                 [Page 5]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

2.2.1.  Signalling of XR Metadata Support

   This document will register with IANA an integer MoQ Extension Header
   type named "xr-metadata".

   The REQUESTED-EXTENSION parameter (key 0x02), if present in the
   CLIENT_SETUP and SERVER_SETUP message, will include the value
   corresponding to the "xr-metadata" MoQ extension header type, if the
   client and server intend to use the "xr-metadata" extension header.

   This document will register with IANA a new setup parameter XR-
   METADATA that is associated with the "xr-metadata" MoQ extension
   header type.  The XR-METADATA parameter indicates the support for
   specific sets of XR metadata.  The XR-METADATA parameter holds a
   value which is the concatenation of two varints:

   The first varint, named '3gpp-xr', identifies the supported set of XR
   metadata:

   *  0x00: No XR metadata.

   *  0x01: Release 18 XR metadata.

   *  0x02: Release 19 XR metadata.

   An endpoint may indicate support for both sets of metadata using a
   value of 0x03.

   The second varint, named '3gpp-xr-options', identifies optional
   metadata:

   *  0x00: No optional metadata.  This value must be used if the first
      varint indicates no XR metadata.

   *  0x01: PSSize and NPDS metadata are included.  This may be used
      with Release 18 or 19 XR metadata.

   The client can include an XR-METADATA parameter in CLIENT_SETUP, to
   request the server to send XR metadata, and to indicate supported XR
   metadata sets and options.  The server can include an XR-METADATA
   parameter in the SERVER_SETUP, to indicate its intent to send XR
   metadata, and to indicate the XR metadata set and option.

2.2.2.  XR Metadata in MOQT Datagrams

   When sending MOQ objects in datagrams, the object XR header includes
   the following fields.

de Foy, et al.            Expires 10 April 2025                 [Page 6]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

   *  When 3gpp-xr bit 0 or 1 is set, the following fields are present
      in every object.

      -  E (1)

      -  D (1)

      -  PSI (4)

      -  PSSN (10)

      -  PSN (6)

   *  When 3gpp-xr bit 1 is set, the following fields are present in
      some objects.

      -  BSize (size TBD)

      -  TTNB (size TBD)

   *  When 3gpp-xr bit 0 or 1 is set, and 3gpp-xr-options bit 0 is set,
      the following fields are present in some objects.

      -  PSSize (24)

      -  NPDS (16)

2.2.3.  XR Metadata in MOQT Streams

   When sending MOQ objects in streams, the object XR header includes
   the following fields.

   *  When 3gpp-xr bit 0 or 1 is set, the following fields are present
      in every object.

      -  D (1)

      -  PSI (4)

      -  PSSN (10)

   *  When 3gpp-xr bit 1 is set, the following fields are present in
      some objects.

      -  BSize (size TBD)

      -  TTNB (size TBD)

de Foy, et al.            Expires 10 April 2025                 [Page 7]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

   *  When 3gpp-xr bit 0 or 1 is set, and 3gpp-xr-options bit 0 is set,
      the following fields are present in every objects.

      -  PSSize (24)

      -  NPDS (16)

   E and PSN are not included and can be derived from QUIC signalling.

3.  Traffic Handling of High-Throughput Low-Latency Traffic

3.1.  MoQ relay Behavior

   A MoQ relay at the ingress point of a wireless network extracts
   metadata associated with PDU sets.

   The relay obtains the PDU set XR metadata from the object XR header,
   and

   *  When objects are transported in MOQT streams, E is derived from
      the FIN flag of the QUIC stream

   *  When objects are transported in MOQT streams, PSN is generated
      based on the QUIC/UDP/IP packets received in order of STREAM frame
      offset.  In case there are missing packets, the relay can use the
      STREAM frame offset and path MTU to determine the sequence number
      of a packet received after one or more missing packets.

   The relay transmits the PDU set XR metadata along with each IP
   packet, to the radio access network, which uses them to apply XR
   traffic handling.

3.2.  Endpoint Behavior

   To enable XR traffic handling, a MoQ client should set up a MOQT
   connection through a MoQ relay providing this functionality.
   Discovery of such relay is out of scope of this document.

   Both MoQ server and client exchange the setup parameter REQUESTED-
   EXTENSION including a varint indicating usage of the 'xr-metadata'
   MoQ extension header type, and the setup parameter XR-METADATA with a
   value indicating the content of the XR metadata extension (as
   described in Section 2.2.1).

   Prior to transmitting an object, an endpoint determines the XR
   metadata applicable to the object, and, if applicable, adds a XR
   metadata extension header into the object header.

de Foy, et al.            Expires 10 April 2025                 [Page 8]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

4.  IANA considerations

   TBD: registrations of the xr-metadata header extension and XR-
   PARAMETER setup parameter.

5.  Security Considerations

   To enable support for the feature described in this document, the
   application exposes metadata to a MoQ relay under the control of a
   network or service operator.  End-to-end encrypted media is not
   exposed to the MoQ relay, so this is not seen as a high-risk
   exposure.

6.  Acknowledgments

   Thanks to Srinivas Gudumasu, who was a contributor to the first
   revision of this draft.  Thanks to Jaya Rao, Ghyslain Pelletier, John
   Kaippallimalil, Sri Gundavelli and Hang Shi for discussions and
   comments about this draft.

7.  Informative References

   [I-D.draft-ietf-mops-ar-use-case]
              Krishna, R. and A. Rahman, "Media Operations Use Case for
              an Extended Reality Application on Edge Computing
              Infrastructure", Work in Progress, Internet-Draft, draft-
              ietf-mops-ar-use-case-18, 19 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mops-ar-
              use-case-18>.

   [I-D.draft-ietf-moq-transport]
              Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
              I. Swett, "Media over QUIC Transport", Work in Progress,
              Internet-Draft, draft-ietf-moq-transport-06, 19 September
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              moq-transport-06>.

   [TR23.700-70]
              3GPP, "Study on architecture enhancement for Extended
              Reality and Media service (XRM); Phase 2", 3GPP, 2024,
              <www.3gpp.org/dynareport/23700-70.htm>.

   [TS23.501] 3GPP, "System architecture for the 5G System", 3GPP, 2024,
              <www.3gpp.org/dynareport/23501.htm>.

   [TS26.522] 3GPP, "5G Real-time Media Transport Protocol
              Configurations", 3GPP, 2024, <www.3gpp.org/
              dynareport/26522.htm>.

de Foy, et al.            Expires 10 April 2025                 [Page 9]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

Appendix A.  XR RTP Header Extension for XR Traffic Handling in 5G
             Networks

   3GPP defined an RTP header extensions for PDU set marking, in
   [TS26.522], which enables a media sender to indicate PDU set metadata
   in each RTP packet.

A.1.  Release 18 XR Metadata

   The fields defined in the Release 18 of 3GPP are included in this
   appendix, for the reader's convenience (text copied from [TS26.522]
   V18.1.0 with minor adaptations and omissions of some notes for
   readability):

   *  *End PDU of the PDU Set [E]* (1 bit): This field is a flag that
      shall be set to 1 for the last PDU of the PDU Set and set to 0 for
      all other PDUs of the PDU Set.

   *  *End of Data Burst [D]* (1 bit): This field is a flag that shall
      be set to 1 for the last PDU of a Data Burst.  It shall be set to
      0 for all other PDUs.  A Data Burst may consist of one or more PDU
      Sets.

   *  *PDU Set Importance [PSI]* (4 bits): The PDU Set Importance field
      indicates the importance of this PDU Set compared to other PDU
      Sets within the same Multimedia Session.  This information may
      help RAN to discard PDUs, when needed.  Lower values shall
      indicate a higher importance PDU Set, with the highest importance
      PDU Set indicated by 1 and the lowest importance PDU Set indicated
      by 15.  When the RTP sender cannot define an importance, it shall
      set the value to 0.

   *  *PDU Set Sequence Number [PSSN]* (10 bits): The sequence number of
      the PDU Set to which the current PDU belongs, acting as a 10-bit
      numerical identifier for the PDU Set. The PSSN shall be
      incremented monotonically by 1 for each subsequent PDU Set.

   NOTE: This value wraps around at 1023, however, using the 16-bit RTP
   packet sequence number and PSSN pair, a receiver may uniquely
   distinguish between any PDU Sets.

   *  *PDU Sequence Number within a PDU Set [PSN]* (6 bits): The
      sequence number of the current PDU within the PDU Set. The PSN
      shall be set to 0 for the first PDU in the PDU Set and incremented
      monotonically for every PDU in the PDU Set in the order of
      transmission from the sender.

de Foy, et al.            Expires 10 April 2025                [Page 10]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

   NOTE: A receiver may use the RTP packet sequence number together with
   the PSN to distinguish between PDUs within a PDU Set that contains
   more than 64 PDUs.

   *  *PDU Set Size [PSSize]* (24 bits): The PDU Set Size indicates the
      total size of all PDUs of the PDU Set to which this PDU belongs.
      This field is optional and subject to an SDP signaling offer/
      answer negotiation, where the RTP sender shall indicate whether it
      will provide the size of the PDU Set for that RTP stream.  If not
      enabled, the field shall not be present within the RTP HE.  If
      enabled, but the RTP sender is not able to determine the PDU Set
      Size for a particular PDU Set, it shall set the value to 0 in all
      PDUs of that PDU Set. The PSSize shall indicate the size of a PDU
      Set including RTP/UDP/IP header encapsulation overhead of its
      corresponding PDUs.  The PSSize shall be expressed in bytes.  It
      is recommended to add the PDU Set Size field when the Number of
      PDUs in the PDU Set field is present.

   NOTE: This field may be optionally present given the signaling of the
   "pdu-set-size" extension attribute in the SDP offer/answer
   negotiation.

   *  *Number of PDUs in the PDU Set [NPDS]* (16 bits): The number of
      PDUs within the PDU Set indicates the total number of PDUs
      belonging to the same PDU Set. This field is optional and subject
      to an SDP signaling offer/answer negotiation, where the RTP sender
      may indicate whether it will provide the number of PDUs within the
      PDU Set for that RTP stream.  If enabled, but the RTP sender is
      not able to determine the Number of PDUs in the PDU Set, it shall
      set the value to 0 in all PDUs of that PDU Set.  It is recommended
      to add the Number of PDUs in the PDU Set field when the PDU Set
      Size field is present.

   NOTE: This field may be optionally present given the signaling of the
   "num-pdus-in-pdu-set" extension attribute in the SDP offer/answer
   negotiation.

A.2.  Release 19 XR Metadata

   Potential additional fields in the Release 19 of 3GPP include (text
   based on work in progress in [TR23.700-70]):

   *  *Burst size [BSize]*: this field describes the size of a burst of
      traffic, which includes one or more PDU sets.

   *  *Time-to-next-burst [TTNB]*: this field describes the time between
      the end of the present burst and the beginning of the next burst.

de Foy, et al.            Expires 10 April 2025                [Page 11]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2024

Authors' Addresses

   Xavier de Foy
   InterDigital
   Canada
   Email: xavier.defoy@interdigital.com

   Renan Krishna
   United Kingdom
   Email: renan.krishna@gmail.com

   Tianji Jiang
   China Mobile
   China
   Email: tianjijiang@chinamobile.com

de Foy, et al.            Expires 10 April 2025                [Page 12]