MOQ Extensions for Relays to Support High-Throughput Low-Latency Traffic
draft-defoy-moq-relay-network-handling-00

MOQ                                                            X. de Foy
Internet-Draft                                               S. Gudumasu
Intended status: Standards Track                            InterDigital
Expires: 24 April 2023                                   21 October 2022

MOQ Extensions for Relays to Support High-Throughput Low-Latency Traffic
               draft-defoy-moq-relay-network-handling-00

Abstract

   This document describes an extension used to convey information about
   media frames, that is used for specific handling by network nodes,
   including error recovery and congestion handling.  These functions
   can be critical to improve energy efficiency and network capacity in
   some (especially wireless) networks.  Due to the end-to-end
   encryption performed in MOQ, MOQ relays are expected to implement
   these functions, and unencrypted metadata will be exposed to MOQ
   relays.  Since we are in the early stages of MOQ protocol design,
   this document initially proposes base protocol requirements.

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

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

de Foy & Gudumasu         Expires 24 April 2023                 [Page 1]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   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.  XR Traffic Handling in 5G Networks  . . . . . . . . . . .   3
     1.2.  Related Handling by RTP Switches  . . . . . . . . . . . .   5
   2.  An Extension for Traffic Handling of High-Throughput
           Low-Latency Traffic . . . . . . . . . . . . . . . . . . .   6
     2.1.  Endpoint Behavior . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Impact on the Base MOQ Protocol . . . . . . . . . . . . .   7
     2.3.  Detailed Description  . . . . . . . . . . . . . . . . . .   8
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Media flows can be carried over wireless networks, which can be
   challenging especially 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 can implement techniques to improve network
   capacity and energy efficiency, as well as reduce the impact of
   packet losses on users, as illustrated here for XR traffic support in
   5G:

   *  The network can handle groups of packets based on how critical
      they are to the user experience.  Some groups of data packets hold
      application data units that are handled together (e.g., decoded)
      by the application. 3GPP defines the term "PDU set" to identify
      these groups of data packets carrying the payload of an
      application data unit [TR23.700-60], which can correspond to the
      data packets of a Network Application Layer (NAL) unit.
      Application data units can depend on other application data units
      to be handled or decoded by the application (e.g., P-frames depend
      on I-frames, and higher layers depend on lower layers).  The
      network can perform differentiated handling of groups of data
      packets, e.g., prioritize some groups over others in case of
      congestion.  The network can also selectively drop data packets
      that depend on an already lost application data unit.

de Foy & Gudumasu         Expires 24 April 2023                 [Page 2]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   *  The network can limit wake-up time (of radios) to transmit and
      receive data.  For this, it should know as much as possible about
      traffic patterns.  The scheduler can benefit from information on
      the size and periodicity of traffic, as well as delay budget and
      expected jitter specific to the application.

   Traffic handling of high-throughput low-latency traffic therefore
   includes differentiated handling of groups of packets, as well as
   configuring lower-layer scheduling.  To perform this, a network node
   can act as, or communicate with, a MOQ relay to obtain the metadata
   it needs, associated with media data.  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
   frame), and provide associated metadata.  Figure 1 describes a MOQ
   relay controlling traffic handling in an access network (for example,
   for media streams 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
   and to metadata not related to its operation.  For interoperability,
   it is also desirable for these mechanisms to not be codec specific.

               +---+  +-----------+  +------------+      +---+
               | A |<-|Access Node|->|            |<---->| B |
               +---+  +----+------+  |            |      +---+
                           +---------+            |
                                     | MOQ Relay  |
                           +---------+            |
               +---+  +----+------+  |            |      +---+
               | C |<-|Access Node|->|            |<---->| D |
               +---+  +-----------+  +------------+      +---+

      Figure 1: Traffic Handling by Access Networks using a MOQ Relay.

1.1.  XR Traffic Handling in 5G Networks

   A MOQ relay located at the ingress point of a wireless network, for
   example within User Plane Function (UPF) or 5G device, can collect
   metadata and use it to handle XR traffic:

de Foy & Gudumasu         Expires 24 April 2023                 [Page 3]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   *  Convey the collected metadata to the Radio Access Network (RAN),
      using GTP-U headers encapsulating the data packets it forwards to
      the RAN (e.g., for dynamic metadata such as packet sequence number
      within the group, priority/importance, dependency information,
      size, group ID).  This makes it possible for the RAN to perform
      differentiated handling on the packets.  The MOQ relay can also
      convey some metadata related to a flow in control messages to the
      RAN (e.g., periodicity, delay budget, jitter range).  This makes
      it possible for the RAN to configure efficient scheduling for the
      flow.

   *  Use the collected metadata to perform some local processing (on
      the UPF or 5G device): locally prioritize groups of packets based
      in case of congestion or drop packets that may no longer
      contribute to a user's perceived QoE, because they can't be
      decoded (missing dependency) or exceeded a delay budget; select a
      path when using multipath.

   Based on the outcome of a study (reaching completion the time of
   writing), 3GPP identifies the following metadata for handling XR
   traffic [TR23.700-60] (the agreed text is available at [S2-2209938]
   until its integration in the report).  Data plane metadata is
   expected to be obtained, for the time being, from RTP/SRTP and their
   extensions headers, or alternatively, from other methods not
   standardized by 3GPP.  Note that it's possible that future releases
   of the 3GPP standard reference other methods, such as one based on
   MOQ.

   *  The following metadata was agreed to be used in the data plane:

      -  ID of a group of packets that share similar handling by the
         network (a "PDU set")

      -  Indication of the first and last data packet in a group
         (optional)

      -  A sequence number of individual packets within the group

      -  Size of a group in number of octets or data packets (optional)

      -  Group importance relative to other groups

   *  Some data plane metadata was not agreed for release 18 but may be
      considered in future releases, including dependency information
      between groups

   *  The following metadata was agreed to be used in the control plane,
      where it is provisioned by the service operator.

de Foy & Gudumasu         Expires 24 April 2023                 [Page 4]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

      -  QoS parameters: target delay budget and error rate for groups

      -  Burst periodicity

      -  Whether all data packets are needed to process the application
         data unit carried by the group

1.2.  Related Handling by RTP Switches

   The RTP extension defined in [I-D.draft-ietf-avtext-framemarking]
   enables an RTP switch (a common short term for various types of
   middleboxes) to access critical information about video frames.  The
   processing by the RTP switch, similarly to the traffic handling
   discussed above for access networks, applies to packets associated
   with encrypted application data units.  Groups of packets typically
   carry a specific layer in a frame.  The examples of processing given
   in the framemarking draft are:

   *  Start/stop forwarding streams at specified boundaries (e.g., on an
      intra-frame).

   *  Determine which frame to drop with minimal impact to video
      quality.

   *  For scalable streams with dependent layers, selectively forward
      specific layers to specific recipients due to recipient bandwidth
      of decoder limits.

   The metadata enabling this behavior is also similar what has been
   identified for XR traffic handling in 5G:

   *  Frame start and end flags (indication of the first and last data
      packet in a group)

   *  Priority/importance of groups of data packets is expressed using
      flags: Independent Frame flag, and Discardable Frame flag.

   *  Dependency information between groups of data packets is expressed
      through: Temporal Layer 0 Picture Index, Base Layer Sync flag,
      Temporal ID, Layer ID.

de Foy & Gudumasu         Expires 24 April 2023                 [Page 5]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

2.  An Extension for Traffic Handling of High-Throughput Low-Latency
    Traffic

   A MOQ extension is proposed to implement this type of handling by the
   network, since the required metadata will not be needed in all cases.
   Note: it may be sufficient to mark the related metadata fields as
   "optional", however using an explicit extension helps telling
   endpoints which fields are expected by relays on the path.

   A MOQ protocol extension (or multiple extensions sharing similar
   design characteristics) can be defined to cover multiple use cases as
   discussed in 2.1 and 2.2.

2.1.  Endpoint Behavior

   To use the proposed extension, the endpoints are expected to perform
   the following:

   *  The application sends media data units, defined in an application
      specific way.  Groups can be identified by stream ID, datagram
      context ID, or using a dedicated group ID present in datagrams.

   *  The application also sends metadata related to the service:

      -  "Per data unit" metadata is expected to change from one media
         data unit to the next, and can include a data unit ID, size,
         importance, dependency information, etc.  The relay should
         receive this metadata before its related media data.  If media
         data is transported in streams, per data unit metadata is sent
         before media in the stream.  If media data is transported in
         datagrams, per data unit metadata is sent in a reliable
         message, which helps reduce the overhead per datagram.

      -  "Per flow" metadata is sent at the beginning of the media flow,
         and may be updated later during the flow lifetime.  This can
         include metadata related to delay budget, error rate, burst
         periodicity.

      -  When media data is sent in datagrams, the application sends
         metadata associated with individual datagrams.  This includes
         metadata that can vary per datagram, such as a datagram
         sequence number within the media data unit, indication of first
         or last datagram.  Some per data unit metadata may also be sent
         in individual datagrams if it enables a more efficient handling
         without too much overhead.

de Foy & Gudumasu         Expires 24 April 2023                 [Page 6]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   *  All related metadata is accessible by the MOQ relays providing the
      service (i.e., cleartext field not end-to-end encrypted but still
      protected by the QUIC connection).

2.2.  Impact on the Base MOQ Protocol

   A few requirements are proposed on the base MOQ protocol to enable
   the type of protocol extensions described in this document.

   *  The base MOQ protocol should support negotiating the use of a
      protocol extension.

      -  An extension corresponds to a set of supported messages, fields
         and associated endpoint behavior

      -  The client should learn of the extensions supported by a MOQ
         relay out-of-band

      -  MOQ relays should be involved in extension negotiation, at
         least to be able to reject a service request if a necessary
         extension is not present in the request

   Potential mechanism: extensions can be negotiated using HTTP headers
   in the extended CONNECT request that initiates the WebTransport
   session.

   *  Assuming a stream based MOQ base protocol:

      -  The extension mechanism should support defining cleartext
         fields (i.e., not end-to-end encrypted) in a stream, placed
         before encrypted media data.

   *  Assuming a datagram based MOQ base protocol:

      -  The extension mechanism should support defining cleartext
         fields in a stream.  This stream contains a cleartext ID that
         is also present in all related datagrams.  This ID can be the
         datagram context ID, or another group ID present in all
         datagrams.

      -  The extension mechanism should support defining cleartext
         fields present in individual datagrams.

   *  The extension mechanism should support defining cleartext fields
      in reliable messages, that relate to a media flow (e.g., using a
      cleartext ID that is present in all streams/datagrams carrying
      data for this media flow)

de Foy & Gudumasu         Expires 24 April 2023                 [Page 7]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   Potential mechanism: cleartext fields (TLVs or frames) can be defined
   as part of the extension and sent by endpoints in streams and
   datagrams (before the encrypted media payload if any).

2.3.  Detailed Description

   TBD (for example: define extension name, define new cleartext fields
   needed by the extension, make some optional MOQ fields mandatory when
   the extension is used, define new messages, etc.)

3.  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.  The encrypted media is not exposed to
   the MOQ relay.  The level of exposure is similar to the Frame Marking
   RTP extension [I-D.draft-ietf-avtext-framemarking].

4.  Acknowledgments

   Thanks to Jaya Rao, Ghyslain Pelletier and Renan Krishna for the
   discussions and comments.

5.  Informative References

   [I-D.draft-ietf-avtext-framemarking]
              Zanaty, M., Berger, E., and S. Nandakumar, "Frame Marking
              RTP Header Extension", Work in Progress, Internet-Draft,
              draft-ietf-avtext-framemarking-13, 11 November 2021,
              <https://www.ietf.org/archive/id/draft-ietf-avtext-
              framemarking-13.txt>.

   [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-06, 8 August 2022,
              <https://www.ietf.org/archive/id/draft-ietf-mops-ar-use-
              case-06.txt>.

   [S2-2209938]
              3GPP, "KI#4&5: Evaluation and Conclusion", 3GPP, 2022,
              <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/
              TSGS2_153E_Electronic_2022-10/Docs/S2-2209938.zip>.

de Foy & Gudumasu         Expires 24 April 2023                 [Page 8]
Internet-Draft            MOQ-EXT-NET-HANDLING              October 2022

   [TR23.700-60]
              3GPP, "Study on architecture enhancement for XR and media
              services", 3GPP, 2022, <www.3gpp.org/
              dynareport/23700-60.htm>.

Authors' Addresses

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

   Srinivas Gudumasu
   InterDigital
   Canada
   Email: srinivas.gudumasu@interdigital.com

de Foy & Gudumasu         Expires 24 April 2023                 [Page 9]