Internet-Draft MOQ-EXT-NET-HANDLING October 2022
de Foy & Gudumasu Expires 24 April 2023 [Page]
Workgroup:
MOQ
Internet-Draft:
draft-defoy-moq-relay-network-handling-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
X. de Foy
InterDigital
S. Gudumasu
InterDigital

MOQ Extensions for Relays to Support High-Throughput Low-Latency Traffic

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.

▲

Table of Contents

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:

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:

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

    • 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

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.
  • 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)

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, , <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, , <https://www.ietf.org/archive/id/draft-ietf-mops-ar-use-case-06.txt>.
[S2-2209938]
3GPP, "KI#4&5: Evaluation and Conclusion", 3GPP, , <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_153E_Electronic_2022-10/Docs/S2-2209938.zip>.
[TR23.700-60]
3GPP, "Study on architecture enhancement for XR and media services", 3GPP, , <www.3gpp.org/dynareport/23700-60.htm>.

Authors' Addresses

Xavier de Foy
InterDigital
Canada
Srinivas Gudumasu
InterDigital
Canada