CMCD transmission over MSF Event Timeline
draft-wilaw-moq-cmcd-event-timeline-00

Media Over QUIC                                                   W. Law
Internet-Draft                                                    Akamai
Intended status: Standards Track                          10 August 2026
Expires: 11 February 2027

               CMCD transmission over MSF Event Timeline
                 draft-wilaw-moq-cmcd-event-timeline-00

Abstract

   Defines the transmission of CMCD data over MSF Event Timeline tracks.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://wilaw.github.io/CMCD-over-MSF-event-timeline/draft-wilaw-moq-
   cmcd-event-timeline-latest.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   wilaw-moq-cmcd-event-timeline/.

   Source for this draft and an issue tracker can be found at
   https://github.com/wilaw/CMCD-over-MSF-event-timeline.

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 11 February 2027.

Copyright Notice

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

Law                     Expires 11 February 2027                [Page 1]
Internet-Draft                CMCD over MSF                  August 2026

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  CMCD mode and key restrictions  . . . . . . . . . . . . . . .   3
   4.  Catalog requirements  . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Publish tracks  . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  CMCD track  . . . . . . . . . . . . . . . . . . . . . . .   3
       4.2.1.  CMCD_DATA object  . . . . . . . . . . . . . . . . . .   4
     4.3.  Configuration . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Example catalog entry . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   MOQT Streaming Format [MSF] defines Event Timeline tracks as a
   generic mechanism for transmitting ad hoc data associated with MSF
   media tracks.  CMCD [CMCD] defines a means by which a media player
   can communicate structured data and have it processed consistently by
   delivery networks and third-party data collection services.  This
   draft specifies how an MSF catalog can instruct a publisher to
   publish configurable CMCD data at a target destination using MSF
   Event Timeline tracks.

   This specification defines transmission for version 2 of CMCD.

2.  Conventions 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.

Law                     Expires 11 February 2027                [Page 2]
Internet-Draft                CMCD over MSF                  August 2026

3.  CMCD mode and key restrictions

   CMCD supports two reporting modes - Request Mode and Event Mode.
   Since Request mode is tied to HTTP requests, which are not present in
   MOQT, this specification constrains CMCD usage to those options
   offered in Event Mode.  Request mode MUST NOT be used.

   Furthermore, there are certain keys under Event Mode which reference
   request semantics and therefore are not allowed in this
   specification.  The keys which MUST NOT be used are: 'ab', 'cmsdd',
   'cmsds', 'd', 'dl', 'h', 'lab', 'nor', 'nr', 'ot', 'rc', 'rtp', 'sf',
   'smrt', 'su', 'tab', 'ttfb', 'ttfbb', 'ttlb' and 'url'.

   The following keys MAY be used in Event Mode: 'bl', 'bg', 'br', 'bs',
   'bsa', 'bsd', 'bsda', 'cen', 'cid', 'cs', 'dfa', 'e', 'ec', 'lb',
   'ltc', 'msd', 'mtp', 'pb', 'pr', 'pt', 'sid', 'sn', 'st', 'sta',
   'tb', 'tbl' and 'tpb'.

   The Event key 'e' MUST NOT use the 'h' and 'rr' tokens.  While the
   'ts' data is mandatory for every report, it is transmitted as the
   index value of each event timeline record.

   When the CMCD spec refers to a 'manifest' in the description of a
   key, interpret that as the 'catalog' in the context of this
   specification.

   The version key 'v' MUST be present in each report and MUST carry a
   value of 2.

4.  Catalog requirements

4.1.  Publish tracks

   A broadcaster triggers a catalog recipient to send CMCD data by
   including a 'publishTracks' (see [MSF] Section 5.1.5) entry.  That
   entry MUST point at a CMCD track Section 4.2.  Multiple CMCD tracks
   MAY be included in the publishTracks array in order to target data at
   different destinations.

4.2.  CMCD track

   A CMCD track defines a track which is to be published by the receiver
   of the catalog.  It defines the configuration of the CMCD data to be
   sent within the payload of that track, as well as the namespace and
   name under which the track will be published.  A CMCD track MUST only
   be included in a 'publishTracks' array and MUST NOT be present in a
   'tracks' array.

Law                     Expires 11 February 2027                [Page 3]
Internet-Draft                CMCD over MSF                  August 2026

   An MSF track carrying [CMCD] data MUST

   *  declare a packaging value of "eventtimeline".

   *  declare an eventType value of "urn:cta:cmcd:2026".

   *  be referenced in the 'publishTracks' array

   *  carry a 'cmcdConfig' Section 4.3 custom track field.

   A CMCD track is an Event Timeline track (See [MSF] Section 8).  The
   "T" wall-clock time index MUST be used.  The 'data' field of each
   timeline entry is defined as a CMCD_DATA object Section 4.2.1.

   Each CMCD track record MUST be published as a new Group unless
   batching is in effect, in which case multiple records MUST be
   accumulated within each Group.  The Group ID SHOULD begin at 0 and
   then increment by one for the duration of the session.

   Each CMCD track record MUST be published as soon as possible after
   the event which triggered it, unless batching is in effect, in which
   case the batching constraints (see Section 4.3) apply.

4.2.1.  CMCD_DATA object

   The CMCD_DATA Object is a sequence of key-value pairs.  The key is a
   string which matches one of the allowed CMCD keys specified in
   Section 3.  The value is always a string and it holds the CMCD-
   defined value for that key.  The value is NOT URLEncoded.

   The 'ts' key MUST NOT appear in the CMCD_DATA Object.  The value of
   the 'ts' key MUST be used as the "T" value of the record index.

   Example CMCD track record

   {
           "T": 1756885678361,
           "data": {
               "sid":"6e2fb550-c457-11e9-bb97-0800200c9a66",
               "bl": 4068,
               "br": "(5000;v 320;a)",
               "bsd": 321,
               "e":"t",
               "sta": "p",
               "v": 2
           }
   }

Law                     Expires 11 February 2027                [Page 4]
Internet-Draft                CMCD over MSF                  August 2026

4.3.  Configuration

   This specification defines a new, custom MOQT track field, intended
   solely for use within a CMCD track.  The name of the field is
   "cmcdConfig" and the value is a JSON [JSON] object.  The purpose of
   this field is to instruct the publisher on which CMCD keys to send in
   the track, how to send them and where to send them.

   The JSON Object contains the following fields:

   *  "events": an array containing one or more triggering events.  Each
      event MUST be in the set ('abs','abe','ae',
      'as','b','bc','c','ce','e','m','pc','pe','pr','ps','sk','t','um').
      This array MUST NOT be empty.

   *  "interval": optional, the time interval in milliseconds between
      't' events.  This field MUST only be present if the 't' event is
      included in the 'events' array.  Intervals below 5000 SHOULD NOT
      be used.

   *  "enabledKeys": an array of the allowed CMCD keys to be included in
      the report.  By default, all keys are excluded so each key MUST be
      explicitly enabled, with the exception of the 'v' key.  The 'v'
      key is mandatory and MUST be included in each record even if it is
      not specified in the 'enabledKeys' array.

   *  "sid": optional, a session ID to use as the value of the 'sid'
      key.  This field MUST only be present if the 'sid' key is included
      in the 'enabledKeys' array.  If not provided and 'sid' is
      specified in the 'enabledKeys' array, then the publisher MUST
      synthesize its own session ID using the guidelines specified in
      [CMCD] Section 4.3.

   *  "batchCount": optional, the number of records to accrue before
      publishing a new Group.

   *  "batchInterval": optional, the minimum interval in milliseconds
      before publishing a new Group.

   If both batchCount and batchInterval are specified, then the
   publisher MUST publish a new Group when either constraint is first
   satisfied.

   An example cmcdConfig track entry, instructing the publisher, every
   30 seconds and at every playstate change, to publish a CMCD record
   containing session ID (which has been provided), buffer length,
   bitrate, play state and absolute buffer starvation CMCD data.

Law                     Expires 11 February 2027                [Page 5]
Internet-Draft                CMCD over MSF                  August 2026

   "cmcdConfig" : {
       "events": ["t","ps"],
       "interval": 30000,
       "enabledKeys": ["sid","bl","br","sta","bsa"],
       "sid":"6e2fb550-c457-11e9-bb97-0800200c9a66"
   }

5.  Example catalog entry

   This catalog excerpt shows the catalog instructing the publisher to
   send CMCD data to 3 different targets.  Each target receives a
   different set of CMCD keys:

   *  The first target is a player monitoring system, which receives
      general health information every 30s.

   *  The second target is a play state monitoring system.  These
      reports are batched and then sent once a minute.

   *  The third target is an error collection system, which receives
      only player errors.

   Note the use of the MSF variable substitution scheme to pass down a
   custom track name.  This is a useful mechanism for giving each end-
   receiver a cacheable catalog while still allowing individualized
   reports.

Law                     Expires 11 February 2027                [Page 6]
Internet-Draft                CMCD over MSF                  August 2026

   "publishTracks": [
       {
         "namespace": "example.com/collection/cmcd/health",
         "name": "%player-id%",
         "packaging": "eventtimeline",
         "eventType": "urn:cta:cmcd:2026",
         "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
         "cmcdConfig" : {
            "events": ["t"],
            "interval": 30000,
            "enabledKeys": ["sid","bl","br","bs","ltc","msd","mtp"]
         }
       },
       {
         "namespace": "example.com/collection/cmcd/playstate",
         "name": "%player-id%",
         "packaging": "eventtimeline",
         "eventType": "urn:cta:cmcd:2026",
         "token": "kkjh68n3DVun23csFGk418kHNU5VDrwb...",
         "cmcdConfig" : {
            "events": ["ps"],
            "batchInterval": 60000,
            "enabledKeys": ["sid","ps"],
            "sid":"6e2fb550-c457-11e9-bb97-0800200c9a66"
         }
       },
       {
         "namespace": "example.com/errors",
         "name": "%player-id%",
         "packaging": "eventtimeline",
         "eventType": "urn:cta:cmcd:2026",
         "cmcdConfig" : {
            "events": ["e"],
            "enabledKeys": ["sid","ec"]
         }
       }
     ]

6.  Security Considerations

   The carriage of CMCD signals within the MSF Event Timeline track
   inherits the security considerations of both the underlying MSF
   transport and the CMCD standard itself.  CMCD data is sent by an
   untrusted player and may therefore be falsified.

   The ability of a publishTrack to direct output at a third-party site
   could be used to DoS both the sender and receiver of the data if the
   CMCD payload were high and the interval low.  Setting a 't' interval

Law                     Expires 11 February 2027                [Page 7]
Internet-Draft                CMCD over MSF                  August 2026

   to 1, for example, would cause a very high report rate.  Client
   implementers SHOULD protect themselves from high report rates by
   coercing low values to a higher, sustainable level.

7.  IANA Considerations

   This document adds one entry to the "MSF Event Timeline Types"
   registry.

      +===================+========================+===============+
      | Event Type        | Description            | Specification |
      +===================+========================+===============+
      | urn:cta:cmcd:2026 | CMCD data transmission | This document |
      +-------------------+------------------------+---------------+

                                 Table 1

8.  Acknowledgments

   Thanks to the IETF MOQ working group and the CTA WAVE CMCD working
   group for their review and input.

9.  Normative References

   [CMCD]     "Common Media Client Data (CTA-5004-B)", 2026,
              <https://cta-wave.github.io/Resources/common-media-client-
              data--cta-5004-b.html>.

   [JSON]     Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

   [MSF]      Law, W. and S. Nandakumar, "MOQT Streaming Format", Work
              in Progress, Internet-Draft, draft-ietf-moq-msf-01, 2 June
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              moq-msf-01>.

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

Law                     Expires 11 February 2027                [Page 8]
Internet-Draft                CMCD over MSF                  August 2026

Author's Address

   Will Law
   Akamai
   Email: wilaw@akamai.com

Law                     Expires 11 February 2027                [Page 9]