Internet-Draft moq-track-switching July 2024
Gurel & Begen Expires 8 January 2025 [Page]
Workgroup:
MOQ
Internet-Draft:
draft-gurel-moq-track-switching-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Gurel
Ozyegin University
A. Begen
Networked Media

Track Switching in Media over QUIC Transport

Abstract

This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.

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 8 January 2025.

▲

Table of Contents

1. Introduction

This document outlines a solution for switching tracks in media delivery over Media Over QUIC Transport (MOQT) [MoQTransport]. Switching tracks is necessary for a variety of reasons, such as changing the quality, the language of the media, or the type of the media (e.g., switching from a video to an audio track). The solution described in this document ensures that there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other.

1.1. Terms and Definitions

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

Client:

The party initiating a MoQ transport session.

Server:

The party accepting an incoming transport session.

Endpoint:

A Client or Server.

Producer:

An endpoint sending media over the network.

Consumer:

An endpoint receiving media over the network.

Transport session:

A raw QUIC connection or a WebTransport session.

Congestion:

Packet loss and queuing caused by degraded or overloaded networks.

Group:

A temporal sequence of objects. A group represents a join point in a track.

Object:

An object is an addressable unit whose payload is a sequence of bytes.

Track:

An encoded bitstream. Tracks contain a sequential series of one or more groups and are the subscribable entity with MOQT.

1.2. Notational Conventions

This document uses the conventions detailed in ([RFC9000], Section 1.3) when describing the binary encoding.

As a quick reference, the following list provides a non-normative summary of the parts of RFC9000 field syntax that are used in this specification.

x (L):

Indicates that x is L bits long

x (i):

Indicates that x holds an integer value using the variable-length encoding as described in ([RFC9000], Section 16)

x (..):

Indicates that x can be any length including zero bits long. Values in this format always end on a byte boundary.

x (L) ...:

Indicates that x is repeated zero or more times and that each instance has a length of L

This document extends the RFC9000 syntax and with the additional field types:

x (b):

Indicates that x consists of a variable length integer encoding as described in ([RFC9000], Section 16), followed by that many bytes of binary data

To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value.

2. Switching Tracks

In MOQT communications, the publisher announces the availability of multiple encodings of a media content in different tracks, which are alternatives of each other and indicated so in the catalog [CommonCatalogFormat]. The subscriber subscribes to one of the tracks from an altGroup in the catalog. During the session, the subscriber may switch from a currently consumed track to any other alternate track from the catalog due to, for example, changes in available bandwidth. To do this, the subscriber can subscribe to a new track and unsubscribe from the old track. Such an action is done by sending a SUBSCRIBE message to the relay. An example of the different tracks indicated in the catalog is shown below.

{
    "tracks":[
        {
          "name": "hd",
          "selectionParams": {
            "width": 1920, "height": 1080,
            "bitrate": 5000000, "framerate": 30
          },
          "altGroup": 1
        },
        {
          "name": "md",
          "selectionParams": {
            "width": 720, "height": 640,
            "bitrate": 3000000, "framerate": 30
          },
          "altGroup": 1
        },
        {
          "name": "sd",
          "selectionParams": {
            "width": 192, "height": 144,
            "bitrate": 500000, "framerate": 30
          },
          "altGroup": 1
        },
        {
          "name": "audio",
          "selectionParams": {
            "codec": "opus", "samplerate": 48000,
            "channelConfig": "2", "bitrate": 32000
          }
        }
      }
    ]
}
Figure 1: An example of the different tracks.

2.1. The Problem and Solution Approaches

Relays do not have access/visibility to the catalog. Therefore, they are unaware when two tracks are alternates. An example of the existing SUBSCRIBE message format is shown below.

SUBSCRIBE Message {
  Subscribe ID (i),
  Track Alias (i),
  Track Namespace (b),
  Track Name (b),
  Filter Type (i),
  [StartGroup (i),
   StartObject (i)],
  [EndGroup (i),
   EndObject (i)],
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}
Figure 2: MOQT SUBSCRIBE message.

Existing SUBSCRIBE message that the subscriber transmits to the relay only contains information of the current track and does not indicate that the client is switching to a new track for the same media content. Therefore, when receiving a SUBSCRIBE message from the subscriber for switching to the new track, the relay may download and transmit both the new track and the old track of the same media content, which can create a bitrate spike and in turn can aggravate an already congested link. Additionally, the player/client application on the subscriber will have to process (e.g., parse and decode) the same media content in overlapping times, which is a waste of computational power.

2.1.1. Solution 1 (altTrackGroup)

A new parameter altTrackGroup can be added to every SUBSCRIBE message. altTrackGroup is the identifier for a group of alternative tracks within the scope of a track namespace. The value of the altTrackGroup identifier may be the same as the altGroup identifier used in the catalog or a different one. An example of a SUBSCRIBE message that includes the identifier altTrackGroup is shown below.

SUBSCRIBE Message {
  Subscribe ID (i),
  Track Alias (i),
  Track Namespace (b),
  Track Name (b),
  Filter Type (i),
  [StartGroup (i),
   StartObject (i)],
  [EndGroup (i),
   EndObject (i)],
  [altTrackGroup (i)],
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}
Figure 3: MOQT SUBSCRIBE message with altTrackGroup.

2.1.2. Solution 2 (Switch Track Alias)

The SUBSCRIBE message can contain an identifier Switch Track Alias such that the Switch Track Alias = Track Alias of the active subscription. This way, this ID in the SUBSCRIBE message can indicate to the relay that this switching request is for an alternative track of the same media content of the current track and assists the relay in seamless switching. An example of a SUBSCRIBE message that includes the identifier Switch Track Alias is shown below.

SUBSCRIBE Message {
  Subscribe ID (i),
  Track Alias (i),
  Track Namespace (b),
  Track Name (b),
  Filter Type (i),
  [StartGroup (i),
   StartObject (i)],
  [EndGroup (i),
   EndObject (i)],
  [Switch Track Alias (i)],
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}
Figure 4: MOQT SUBSCRIBE message with Switch Track Alias.

3. Security Considerations

TODO: Expand this section.

4. IANA Considerations

TODO: Expand this section.

5. References

5.1. Normative References

[MoQTransport]
Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-04>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

5.2. Informative References

[CommonCatalogFormat]
Nandakumar, S., Law, W., and M. Zanaty, "Common Catalog Format for moq-transport", Work in Progress, Internet-Draft, draft-ietf-moq-catalogformat-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-catalogformat-00>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.

Authors' Addresses

Zafer Gurel
Ozyegin University
Ali Begen
Networked Media