Track Switching in Media over QUIC Transport
draft-gurel-moq-track-switching-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
Document | Type | Active Internet-Draft (individual) | |
---|---|---|---|
Authors | Zafer Gürel , Ali C. Begen | ||
Last updated | 2024-07-07 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-gurel-moq-track-switching-00
MOQ Z. Gurel Internet-Draft Ozyegin University Intended status: Standards Track A. Begen Expires: 8 January 2025 Networked Media 7 July 2024 Track Switching in Media over QUIC Transport draft-gurel-moq-track-switching-00 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. 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. 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. Gurel & Begen Expires 8 January 2025 [Page 1] Internet-Draft moq-track-switching July 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 2 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Switching Tracks . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Problem and Solution Approaches . . . . . . . . . . . 5 2.1.1. Solution 1 (altTrackGroup) . . . . . . . . . . . . . 6 2.1.2. Solution 2 (Switch Track Alias) . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 Gurel & Begen Expires 8 January 2025 [Page 2] Internet-Draft moq-track-switching July 2024 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. Gurel & Begen Expires 8 January 2025 [Page 3] Internet-Draft moq-track-switching July 2024 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. Gurel & Begen Expires 8 January 2025 [Page 4] Internet-Draft moq-track-switching July 2024 { "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. Gurel & Begen Expires 8 January 2025 [Page 5] Internet-Draft moq-track-switching July 2024 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. Gurel & Begen Expires 8 January 2025 [Page 6] Internet-Draft moq-track-switching July 2024 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. Gurel & Begen Expires 8 January 2025 [Page 7] Internet-Draft moq-track-switching July 2024 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, 29 May 2024, <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, March 1997, <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, May 2017, <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, 17 June 2024, <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, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>. Authors' Addresses Zafer Gurel Ozyegin University Email: zafer.gurel@ozu.edu.tr Gurel & Begen Expires 8 January 2025 [Page 8] Internet-Draft moq-track-switching July 2024 Ali Begen Networked Media Email: ali.begen@networked.media Gurel & Begen Expires 8 January 2025 [Page 9]