Track Switching in Media over QUIC Transport
Internet-Draft draft-gurel-moq-track-switching-00
Zafer Gurel
Ozyegin University
zafer.gurel@ozu.edu.tr
Ali Begen
Networked Media
ali.begen@networked.media
Applications and Real-Time
MOQ
Internet-Draft
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.
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.
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.
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.
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.
An example of the different tracks.

{
    "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
          }
        }
      }
    ]
}

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.
MOQT SUBSCRIBE message.

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 (..) ...
}

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.
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.
MOQT SUBSCRIBE message with altTrackGroup.

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 (..) ...
}

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.
MOQT SUBSCRIBE message with Switch Track Alias.

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 (..) ...
}

Security Considerations
TODO: Expand this section.
IANA Considerations
TODO: Expand this section.
References
Normative References
[MoQTransport]

Media over QUIC Transport
Luke Curley
Discord
Kirill Pugin
Meta
Suhas Nandakumar
Cisco
Victor Vasiliev
Google
Ian Swett
Google
29 May 2024
Internet-Draft draft-ietf-moq-transport-04
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[CommonCatalogFormat]

Common Catalog Format for moq-transport
Suhas Nandakumar
Cisco
Will Law
Akamai
Mo Zanaty
Cisco
17 June 2024
Internet-Draft draft-ietf-moq-catalogformat-00
[RFC9000]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000