MSYNC
draft-bichot-msync-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Sophie Bale , Remy Brebion , Guillaume Bichot | ||
| Last updated | 2023-04-20 (Latest revision 2023-04-17) | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Reviews |
ARTART Early review
(of
-08)
by Christian Amsüss
On the Right Track
|
||
| Stream | ISE state | Response to Review Needed | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists::Revised I-D Needed | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bichot-msync-11
Internet-Draft S. Bale
Intended Status: Informational R. Brebion
Expires: October 19, 2023 G. Bichot
Broadpeak
April 17, 2023
MSYNC
draft-bichot-msync-11
Abstract
This document describes the Multicast Synchronization (MSYNC)
Protocol that aims at transferring video media objects over IP
multicast. Although generic, MSYNC has been primarily designed for
transporting HTTP adaptive streaming (HAS) objects including
manifest/playlists and media segments (e.g., CMAF) according to an
HAS protocol such as Apple HLS or MPEG DASH between a multicast
sender and a multicast receiver.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2023 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
Bale et aL. Expires October 19, 2023 [Page 1]
Internet-Draft MSYNC April 17, 2023
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. A typical MSYNC deployment . . . . . . . . . . . . . . . . 5
2.2. The unicast Networks . . . . . . . . . . . . . . . . . . . 8
2.3. The Multicast Network and congestion avoidance . . . . . . 8
2.4. Handling third party content . . . . . . . . . . . . . . . 10
3. MSYNC Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. MSYNC Packet Format . . . . . . . . . . . . . . . . . . . . 10
3.2. Object Info Packet . . . . . . . . . . . . . . . . . . . . 12
3.3. Object Data Packet . . . . . . . . . . . . . . . . . . . . 14
3.4. Object HTTP Header Packet . . . . . . . . . . . . . . . . . 15
3.5. Object Data-part Packet . . . . . . . . . . . . . . . . . . 16
3.6. Maximum Size of an MSYNC Packet . . . . . . . . . . . . . . 17
3.7. Sending and Receiving MSYNC Objects . . . . . . . . . . . . 18
3.7.1. Mapping over Transport Multicast Sessions . . . . . . . 18
3.7.2. Detecting the End of an Object Reception . . . . . . . 19
3.7.3. Congestion Control . . . . . . . . . . . . . . . . . . 20
3.8. HAS Protocol Dependency . . . . . . . . . . . . . . . . . . 21
3.8.1. Object Info Packet . . . . . . . . . . . . . . . . . . 21
3.8.1.1. Media Sequence . . . . . . . . . . . . . . . . . . 21
3.8.1.2. Object URI . . . . . . . . . . . . . . . . . . . . 22
3.8.2. Sending Rules . . . . . . . . . . . . . . . . . . . . . 23
3.9. RTP as the Transport Multicast Session Protocol . . . . . . 23
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Normative References . . . . . . . . . . . . . . . . . . . 26
6.2. Informative References . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Bale et aL. Expires October 19, 2023 [Page 2]
Internet-Draft MSYNC April 17, 2023
1 Introduction
Transporting media content over multicast is known to be very
effective for saving network resources (bandwidth). Multicast is used
by Internet service providers for providing IPTV services.The IPTV
technology relies essentially on MPEG Transport Stream (MPEG TS)
format, UDP transport and IP multicast while the HTTP adaptive bit-
rate streaming (HAS), a unicast "Over The Top" technology relies on
HTTP /TCP, new container formats (as MP4/CMAF) and signaling
protocols (Apple HLS, MPEG DASH). With the generalization of HAS
streaming there is a need to operate IP multicast in order to achieve
the same level of network efficiency provided by an IPTV service.
MSYNC allows transporting HTTP based ABR flows over multicast relying
on IP/UDP and optionally RTP that makes it particularly suited for
transitioning IPTV legacy (MPEG2 TS) to the HAS ecosystem. MSYNC is
simple (congestion avoidance, no forward error correction) although
reliable (enable easy coupling with a unicast based repair protocols)
and extensible; it has been experimented and deployed over various
IPTV infrastructures (xDSL, cable, fiber) and broadcast networks
(satellite).
Note that it is assumed that multicast distribution within or between
autonomous systems is possible only with a pre-arranged capacity
planning.
Note that
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2 Definitions
ABR: Adaptive Bit Rate streaming is the method that consist in
changing the [media] encoding bit-rate function of the network
condition.
HTTP/1.1 CTE: Chunked Transfer Encoding. A method for object delivery
over HTTP1.1 of unknown size. See Section 7.1 of [RFC9112]
HTTP Adaptive Streaming (HAS) protocol: an ABR method based on HTTP
and signaling procedures described in [MPEGDASH] and in
[RFC8216].
HTTP Adaptive Streaming (HAS) session: Transport one or more media
streams (e.g., one video, two audios, One subtitle) according to
Bale et aL. Expires October 19, 2023 [Page 3]
Internet-Draft MSYNC April 17, 2023
HTTP. A HAS session is triggered by a player downloading first a
manifest file, then an init segment and/or media segments
(belonging to possibly different sub-streams according to the
selected representation) and possibly more manifest files
according to the HAS protocol.
init segment: A piece of a media sub-stream used to initialize the
decoder as specified in [MPEGCMAF].
manifest: A file gathering the configuration for conducting a
streaming session; corresponds to a play list as defined by HLS
[RFC8216]. During a HAS streaming session, a manifest or
playlist can be modified.
media: A digitalized piece of video, audio, subtitle, image, etc.
media stream: Gathers one or more media sub-streams.
media sub-stream: A version of a media encoded in a particular bit-
rate, format and resolution; also called representation or
variant stream.
media segment: A piece of a media sub-stream of a fixed duration
(e.g., 2s) as specified in [MPEGCMAF].
media chunk: A piece of a media segment of a fixed duration as
specified in [MPEGCMAF].
MSYNC object: As part of a HAS session carried over MSYNC, an MSYSNC
object can be an addressable HAS entity like an initialization
segment, a media segment (or fragment, or chunk), a manifest (or
playlist). An MSYNC object can also be a non-addressable
transport entity like a part of a segment (an HTTP2 frame or an
HTTP/1.1 CTE block). An MSYNC object is sent by an MSYNC sender
over a transport multicast session and receives by an MSYNC
receiver.
MSYNC super object. When an object to be transmitted is composed of
parts delivered on the fly when available in such a way the size
of an object to be transmitted is unknown in advance, it is
called a super object. A super object may correspond to a stream
or a media segment not yet completely generated/received and for
which the size is therefore unknown.
MSYNC packet: The transport unit of MSYNC. Several MSYNC packets MAY
be used to transport an MSYNC object.
MSYNC receiver. The MSYNC end point that receives MSYNC objects over
Bale et aL. Expires October 19, 2023 [Page 4]
Internet-Draft MSYNC April 17, 2023
multicast according to MSYNC. It is typically part of a
multicast gateway that receives MSYNC objects relying on the
MSYNC receiver and reconstructs/serves in unicast the original
HAS session on demand (i.e. based on HAS player requests).
MSYNC sender. The MSYNC end point that sends MSYNC objects over
multicast according to MSYNC. It is typically part of a
multicast server that acquires HAS session payload and send it
over multicast as MSYNC objects relying on the MSYNC sender.
representation: A media sub-stream as defined by [MPEGDASH];
corresponds to a variant stream as defined by HLS [RFC8216].
variant stream: A media sub-stream as defined by HLS [RFC8216];
corresponds to a representation as defined by [MPEGDASH].
MSYNC channel: The set of transport multicast sessions carrying a HAS
session as a set of MSYNC objects.
MSYNC control channel: the transport multicast session carrying
control plane MSYNC objects. As part of the control channel, an
MSYNC object may transport some control plane information (as
e.g., the MSYNC receiver configuration).
IP multicast session: A session gathering transport multicast
sessions having the same source IP address and destination
multicast IP address.
transport multicast session: Operating a transport protocol that is
based UDP over IP multicast. A transport multicast session is
identified by the transport (UDP) port number, the source IP
address and the IP multicast address.
RTP multicast session: A transport multicast session based on RTP as
defined in [RFC3550].
2. Overview
2.1. A typical MSYNC deployment
MSYNC is a protocol typically (but not only) used between a multicast
server (hosting the MSYNC sender) and a multicast gateway (hosting
the MSYNC receiver) as represented in the figure 1 (arrows represent
the HAS session elements directional flows). The multicast server
acquires HAS session elements in unicast conforming to a HAS protocol
as e.g., MPEG DASH [MPEGDASH] or HLS [RFC8216] and sends those HAS
session elements over a multicast network according to MSYNC
Bale et aL. Expires October 19, 2023 [Page 5]
Internet-Draft MSYNC April 17, 2023
supporting [possibly RTP/] UDP/IP multicast up to the multicast
gateways. A multicast gateway listens the corresponding multicast
flows and serves the HAS player(s) in unicast conforming to the same
HAS protocol. MSYNC permits a sender to serve simultaneously multiple
receivers conforming to one or several HAS protocols and formats
(e.g., assuming one shared multicast network, one sender could serve
some receivers with MPEG DASH compliant content and some other
receivers with HLS compliant content).
The Multicast server is configured (by e.g., the ISP operating the
multicast network) in order to acquire HAS content from a Content
Distribution Network (CDN) in unicast typically over Internet.
Considering one among several possible content ingest methods (e.g.,
HTTP GET), for each HAS session, the multicast server behaves as a
sort of HAS player, reading the manifest, discovering the available
representations and downloading concurrently media segments of all
(or a subset) of the available representations. Finally, the
multicast server is configured for sending all those HAS session
elements over [possibly RTP/] UDP/IP multicast according to a certain
UDP/IP flow arrangement (for example all the objects related to each
video representation are sent over a separate multicast transport
session (multicast IP address + port number) whereas all audio
representations are sent over the same transport multicast session.
The Multicast gateway is configured (by the same ISP having
configured the multicast server) for being aware of the same UDP/IP
flow arrangement. Depending on this arrangement and on the HAS player
request, the MSYNC receiver "Joins" the multicast IP group
associated with the HAS representation requested by the HS player.
Note that the multicast gateway might not be capable of receiving all
the concurrent transport multicast sessions in the same time per
bandwidth restriction (e.g., ADSL).
At any time, the multicast gateway can detect corrupted and/or lost
packets and attempt to repair using a repair protocol. This is
possible with the HAS server interacting with the HAS content
delivery network (CDN) or thanks to the RTP protocol if used as the
transport layer over UDP (See Section 3.9).
The multicast gateway receives the MSYNC objects and is ready to
serve them (e.g., acts as a local cache). Whenever a HAS request is
sent by a media player and received by the multicast gateway, the
latter reads first its local cache. In case of cache hit, it returns
the object. In case of cache miss, the multicast gateway can possibly
retrieve the requested object from the associated CDN (or a dedicated
server) over a unicast interface (if existing) through operating HTTP
conventionally and forwards back to the HAS player the object once
retrieved.
Bale et aL. Expires October 19, 2023 [Page 6]
Internet-Draft MSYNC April 17, 2023
Unicast server Multicast server
+-------- + + -------------------- +
| HAS | ---- unicast --> | HAS | MSYNC |
| CDN | Internet | Ingest | Sender |
+ ------- + + ---------------------+
| |
| |
-----------unicast ---------- multicast
Internet | |
| |
v V
+-------- + + -------------------- +
| HAS | <--- unicast --- | HAS | MSYNC |
| Player | Local | Server |Receiver |
+ ------- + + ---------------------+
End-user Multicast gateway
terminal
Figure 1: example of MSYNC deployment
With MSYNC deployed over a multicast network, the HAS player gets the
HAS content in full transparency (i.e. the player is absolutely
unaware of getting the content through MSYNC or not).
Note that nothing precludes the MSYNC receiver or even the multicast
gateway to be co-located with the media player and therefore embedded
in the end-user terminal as shown in the figure 2.
Multicast server
+-------- + + -------------------- +
| HAS | --- unicast --> | HAS | MSYNC |
| Server | Internet | Player | Sender |
+ ------- + + ---------------------+
| |
| |
unicast multicast
Internet |
| |
v |
+ ----------------- + |
| HAS | MSYNC |<-------------------------
| Player |Receiver |
+ ------------------+
End-user terminal
Figure 2: MSYNC receiver in the terminal
Bale et aL. Expires October 19, 2023 [Page 7]
Internet-Draft MSYNC April 17, 2023
2.2. The unicast Networks
The figure 1 shows a typical MSYNC deployment where a HAS player
interacts with an HAS server in an unicast way over e.g., Internet
and interacts with a multicast gateway over e.g., a local network
according to the same HAS protocol. Note that the multicast gateway
may reside in the local area network (LAN) or upstream, in the ISP's
network premises.
In theory, all interfaces labeled "unicast" in the figure 1 could be
deployed over an Internet network although practically, the interface
between the end-user terminal and the multicast gateway corresponds
to a broadband access network or a Local area network (LAN)
controlled by the ISP.
2.3. The Multicast Network and congestion avoidance
The multicast network is typically provided and controlled by a
broadband Internet service Provider (or a broadcast service
provider). The multicast network is composed with one or several
multicast sub-networks interconnected with multicast routers and/or
layer 2 bridge/switches performing IGMP snooping (Multicast Listener
Discovery in IPv6) as discussed in [RFC4541] allowing to
duplicate/forward multicast IP packets based on IGMP messaging. In a
broadband multicast infrastructure the multicast network
interconnects a service end-point (e.g., an IPTV service) with a
broadband gateway located in the end-user premises. The last
multicast sub-network is typically a point-to point circuit/line
between the end-user broadband gateway and the first access network
infrastructure aggregation point (e.g., a DSL access module or
DSLAM). It has a rather limited [bandwidth] capacity comparing with
the other multicast sub-networks being part of the ISP's access
aggregation and core networks.
The MSYNC sender is connected to the first multicast sub-network
whereas the MSYNC receiver is connected to the last multicast sub-
network. A multicast network provides a certain capacity (i.e.,
bandwidth) attached to the first sub-network (connected to the MSYNC
sender) that may be different from the capacity attached to the last
sub-network connected to the MSYNC receiver. The data transported
(i.e., HAS session elements) by MSYNC is not assumed elastic, i.e.,
it SHOULD be ingested at a fixed rate, sharing the concerns expressed
by [RFC3550] (Section 10).
The multicast network must provide quality of service means allowing
to pre-provision bandwidth resource. This assumption permits to
configure the MSYNC sender to transmit one HAS session or
concurrently several HAS sessions operating one or more transport
Bale et aL. Expires October 19, 2023 [Page 8]
Internet-Draft MSYNC April 17, 2023
multicast session up to a certain maximum bandwidth, said
MAX_BW_SEND. MAX_BW_SEND corresponds to the minimum guaranteed
bandwidth dedicated to MSYNC allowing to transport the provisioned
HAS session(s) across all multicast sub-networks up to the last
multicast sub-network ingress point (e.g., the last router or bridge)
before reaching the MSYNC receiver.
The MSYNC sender MUST control the sending rate of each HAS media sub-
stream (and generally speaking of all MSYNC object to be transmitted)
in such a way the maximum bandwidth MAX_BW_SEND corresponds to: 1/the
sum of all individual media sub-stream bit-rate composing the set of
provisioned HAS session(s) and 2/ an additional bandwidth reserve for
supporting control (initialization segments, manifest file,
configuration file) transmission.
In addition, the MSYNC sender MUST be configured in such way, the
minimum bandwidth consumed by an HAS session as advertised by a
manifest (the least bandwidth consuming combination of media sub-
streams as e.g., video, audio, subtitling) remains within the
smallest provisioned bandwidth dedicated to MSYNC over the last
multicast sub-network (connected to the N MSYNC receivers), said min
(MAX_BW_RECEIVE_1, MAX_BW_RECEIVE_2, MAX_BW_RECEIVE_3,...,
MAX_BW_RECEIVE_N). There is one MAX_BW_RECEIVER restriction per MSYNC
receiver as there might be up to one different multicast sub-network
connected to each MSYNC receiver. With this approach, any MSYNC
receiver (whatever the last multicast sub-network capacity) fed by
the MSYNC sender is ensured to receive for each HAS session, at least
one HAS sub-streams combination. The MSYNC sender MAY send a manifest
and related media sub-streams for which a combination of such media
sub-streams could result in a throughput higher than the
MAX_BW_RECEIVE of some MSYNC receivers.
The MSYNC receiver is instructed to join one or more IP multicast
sessions up to its maximum bandwidth constraint (MAX_BW_RECEIVE) that
represents the provisioned capacity dedicated to MSYNC over the last
multicast sub-network it is connected to. As an example, the
capacity of the last multicast sub-network can be limited to a few
Mbps with ADSL and up to several hundred of Mbps with fiber to the
home (FTTH). In the case of a broadcast network (e.g., satellite)
the capacity exposed to the MSYNC sender may be equivalent to the
capacity exposed to the MSYNC receiver if the broadcast network is
composed with only one sub-network.
The MSYNC receiver MUST support IGMP version 2 [RFC2236] in order to
"join" and "leave" an IP multicast session, When source filtering (
Source-Specific Multicast or SSM) is required the MSYNC receiver MUST
support IGMP version 3 [RFC3376] instead.
Bale et aL. Expires October 19, 2023 [Page 9]
Internet-Draft MSYNC April 17, 2023
The way to send and receive MSYNC packets over a transport multicast
session is detailed in 3.7. In particular, the session discusses the
way to manage potential congestion situations.
2.4. Handling third party content
As introduced above, MSYNC is an enabler for allowing HAS content to
be distributed over a controlled multicast network. Ideally any third
party (content provider or content delivery network provider) siting
on Internet should be able to operate this multicast delivery as
enabled by MSYNC. Content Distribution Network Interconnection (CDNi)
is a framework [RFC7336] for a content provider or an upstream CDN
provider to delegate streaming to a downstream CDN. Regarding HAS
streaming, CDNi is used to improve the user experience, allowing the
third party content provider to operate a downstream CDN owned,
shared and exposed by an ISP through the Open caching interfaces
specified by the CDNi framework. The delegation is basically done
through request routing where an upstream request router sitting in
Internet redirects a request to a cache server sitting in the ISP's
domain. Advantages and benefits are disclosed in [RFC6770] and in
particular in Section 2.3 that discusses the mutual benefits for the
ISP and the content/CDN provider in the context of video streaming.
Let's now assume that the ISP desires to share and open its multicast
delivery service and infrastructure powered by MSYNC in a similar
way. This may be completely transparent for the content provider.
According to the CDNi framework, HAS session request can be delegated
to (i.e., routed) down to the ISP's HAS server hosted by the
multicast gateway in figure 1.
In summary with the CDNi framework and MSYNC combined together, HAS
streaming over Internet can leverage the ISP's multicast network
delivery (powered by MSYNC) in an open/standard way.
3. MSYNC Protocol
3.1. MSYNC Packet Format
The MSYNC packet has the following format. All bytes are sent
according to the conventional network order: big-endian.
Bale et aL. Expires October 19, 2023 [Page 10]
Internet-Draft MSYNC April 17, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | packet type | object identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| data |
| .... |
Figure 3: MSYNC Packet
version: 8 bits
version of the MSYNC protocol = 0x3
packet type: 8 bits
Defines the MSYNC packet type. The sub-header and the associated
data (if any) are dependent on the packet type. The following
types are defined.
0x01: object info
0x02: object info redundancy packet
0x03: object data
0x04: reserved
0x05: object http header
0x06: object data-part as a piece of an object data for
transporting e.g., an MPEG CMAF chunk, an HTTP/1.1 chunk or yet
an HTTP/2 frame.
object identifier: 16 bits
The field identifies the object being transferred in a multicast
transport session. Considering one transport multicast session,
all MSYNC packets associated with the same object carry the same
object identifier in their MSYNC packet header. Whenever this
object ID change that means the sending of the previous object is
finished but not necessarily the reception (packets might have
been possibly reordered). Depending on the deployment, un-ordered
packet reception is either not possible or acceptable within a
certain time limit. When transmitting a new object, the MSYNC
sender MUST NOT reuse an object ID that corresponds to an ongoing
MSYNC object transmission. The way to deal with packet re-ordering
is discussed in Section 3.7.
sub-header: series of N x 32 bits
The packet sub-header is linked to the packet type. The details of
each packet type is given in the next sections.
Bale et aL. Expires October 19, 2023 [Page 11]
Internet-Draft MSYNC April 17, 2023
data: series of D x 8 bits
This field is optional and is present depending on the packet
type. D is bounded by the maximum size of a transport multicast
session protocol packet size and the MTU (Maximum Transfer Unit)
otherwise as explained in Section 3.6.
3.2. Object Info Packet
The Object info packet is used to transport the meta-data
associated with an object. It permits to characterize the object
in term of e.g., size and type. The object information is carried
over one object info packet only. The object info packet is
typically sent along with the object data it describes.
The object identifier corresponds to the object identifier of the
object data packets (or the object data-part packets) the object
info packet relates to.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | packet type | object identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of MSYNC packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object type | Reserved | mtype | object URI size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| media sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| object URI |
: :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Object Info packet
packet type: 0x01 or 0x02
Redundant object INFO packets (packet type 02) MAY be sent in
addition to the "main" object info packet according to Section
3.7.
object size: 32 bits
The number of bytes that compose the object payload transported
Bale et aL. Expires October 19, 2023 [Page 12]
Internet-Draft MSYNC April 17, 2023
with a MSYNC object data packet (Section 3.3) or MSYNC object
data-part packet (Section 3.5). The maximum size of an object (4.4
Gbytes) authorizes the transfer of a video segment of several tens
of seconds, 4K encoded.
The size may be 0 indicating that there is no corresponding
object's payload transmission foreseen (i.e., no expected MSYNC
data packet or MSYNC data-part packet). In case of a super object
transmission (Section 3.5), If the object URI of an object info
with an object size set to 0 matches the super object URI then it
MUST be interpreted as the end of the super object transmission
(Section 3.8.1.2).
number of MSYNC packets: 32 bits
Number of MSYNC packets that compose the transported object. If
the object size is null (set to 0) then the number of MSYNC
packets MUST be null (set to 0).
object CRC: 32 bits
A CRC-32 applied to the object data payload for corruption
detection.
object type: 8 bits
Defines the type of object, i.e., the content type transported
with Object data (or data-part) packets, associated with this
MSYNC Object info packet.
0x00: reserved for future use.
0x01: media manifest (playlist)
0x02: unknown
0x03: media data or data-part: Transport stream (MPEG2-TS)
0x04: media data or data-part: MPEG4 (CMAF)
0x05: control: control plane information (e.g., multicast
gateway configuration)
0x06-0xFF: Reserved
mtype: 4 bits
Characterizes the media manifest. This field MUST only be used in
association with the object type 0x01 (media manifest). It MUST be
set to 0x00 (not applicable) otherwise. The field can take the
following values.
0x00: Not Applicable
0x01: MPEG Dash as specified in [MPEGDASH].
0x02: Master HLS playlist as specified in [RFC8216].
0x03: Media HLS playlist as specified in [RFC8216].
0x04-0xF: Reserved
object URI size: 12bits
The size in bytes of the object URI field. The value MUST
Bale et aL. Expires October 19, 2023 [Page 13]
Internet-Draft MSYNC April 17, 2023
guarantee that the MSYNC info packet size is not greater than the
network MTU.
media sequence: 32 bits
It is a sequence number associated with the MSYNC objects data and
data-part (for transporting a segment or a manifest). It is
dependent on the mtype value. It is used to synchronize unicast
and multicast receptions in the multicast gateway. The values and
rules are detailed in the Section 3.8 dedicated to the HAS
protocol dependencies. If this field is unused, it MUST be set to
0x00, and MSYNC receivers MUST ignore it.
object URI: Quotient ((object URI size * 8)/32) bits + 32 bits if
remainder ((object URI size * 8)/32) >0
This the path name associated with the object. It MAY corresponds
to a storage/Cache path. There SHOULD be a direct relationship
between this URI and the URL associated with the addressable
object (e.g., HAS segment or CMAF chunk and/or a manifest). The
rules for HAS delivery are detailed in Section 3.8 dedicated to
the HAS protocol dependencies.
The object URI is coded as a series of string characters.
Remaining non used bytes of the last 32 bits field MUST be filled
with the 0x00 value.
3.3. Object Data Packet
This MSYNC packet carries part or all of the object's data
payload. The type of data and the way to process the object's data
packets are function of the associated object's info packet.
Object payload is transported through a series of object data
packets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | packet type | object identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
: :
: :
Figure 5: Object Data packet
packet type: 0x03
Bale et aL. Expires October 19, 2023 [Page 14]
Internet-Draft MSYNC April 17, 2023
object offset: 32 bits
The index from which the MSYNC object data packet payload is to be
written in order to compose the object data at the receiver side
(i.e., the multicast gateway). The first data packet of an object
has an offset equal to 0.
data: N x 8bits
The size N is not declared; it is bounded by the maximum size of
the under-laying transport multicast session packet (e.g., RTP) as
depicted in Section 3.6. The total size (number of bytes) of the
object data is indicated in the associated object info (field
object size).
3.4. Object HTTP Header Packet
Using the Object HTTP header is optional (see 3.7). The MSYNC
sender and the MSYNC receiver do not exploit directly the HTTP
header. HTTP header fields can be use by the application operating
MSYNC. For example, considering the Figure 1, the HAS Ingest
component in the multicast server may ingest some HTTP headers
useful for the HAS server in the multicast gateway to be served to
the HAS player.
The HTTP header packet carries part or all of HTTP header fields
related to the object to be sent. There is at most one Object HTTP
header per Object data (or data-part) that can be repeated.
The transport of the HTTP header fields MUST be conformed to
HTTP/1.1 Section 5 of [RFC9112]. Carrying HTTP header fields of a
version of HTTP greater than HTTP/1.1, the MSYNC sender MUST
convert the format according to HTTP/1.1 Section 5 of [RFC9112].
The object identifier is the same than the one present in the
object data packets or object data-part packets it relates to.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | packet type | object identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header size | header offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
: :
: :
Figure 6: Object HTTP Header packet
Bale et aL. Expires October 19, 2023 [Page 15]
Internet-Draft MSYNC April 17, 2023
packet type: 0x05
header size: 16 bits
An object HTTP header can be transported over one or several
under-laying transport packets. This field indicates the total
size of the HTTP header in bytes and it is indicated in each the
HTTP header's packet.
header offset: 16 bits
The index from which this HTTP header MSYNC packet payload data is
to be written in order to complement the HTTP header at the
receiver side (i.e the multicast gateway). The first packet of the
HTTP header has an offset equal to 0.
data: N x 8bits
The size N is not declared; it is bounded by either the header
size field value or by the maximum size of the under-laying
transport packet (e.g., RTP) as explained in Section 3.6.
3.5. Object Data-part Packet
This MSYNC packet carries part or all of the media data-part
object payload. The type of data and the way to process the
object's data-part packets are function of the associated info
packet. Object payload is transported through a series of object
data-part packets. The data-part is used when the object
corresponds to a "part" (a block) of a super object for which the
size is unknown (a super object may correspond to a stream or a
media segment not yet complete and for which the size is therefore
unknown).
All data-part packets belonging to the same data part object have
the same object identifier that is the same one present in the
object info packet and HTTP header (if any) packets the data-part
object relates too.
All data-part objects composing a super object have a different
object identifier. The way to link data-part objects with a super
object is thanks to the object info packet (object URI) as
explained in Section 3.8.1.2.
The end of super-object transmission is signaled with an object
info packet having both the object size and the number of MSYNC
packets set to 0 and having the object URI matching the object URI
of the already received parts according to Section 3.8.1.2.
Bale et aL. Expires October 19, 2023 [Page 16]
Internet-Draft MSYNC April 17, 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | packet type | object identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| super object offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
: :
: :
Figure 7: Object Data-part packet
packet type: 0x06
object offset: 32 bits
The index from which the data-part packet payload is to be written
in order to compose the object data-part at the receiver side
(i.e., the multicast gateway). The first packet of the data-part
has an offset equal to 0.
super object offset: 32 bits
The index from which the object part-data packet payload is to be
written in order to compose the super object data at the receiver
side (i.e., the multicast gateway). The first data-part object
composing a super object has the super object offset equal to 0.
The super object offset is the same for all object data-part
packets composing the same object data-part.
data: N x 8bits
The size N is not declared; it is bounded by the maximum size of
the under-laying transport packet (e.g., RTP) as depicted in the
Section 3.6. The total size (number of bytes) of the object data
is indicated in the associated object info (field object size).
3.6. Maximum Size of an MSYNC Packet
An MSYNC packet MUST fit within the underlying protocol packet. As
detailed in Section 3, an MSYNC packet is composed with a header
part and a data part for which the size is limited by the
transport multicast protocol. With RTP and/or UDP (which authorize
up to 65535 bytes), then the maximum size is linked to the path
MTU (Maximum Transfer Unit) as the largest transfer unit supported
between the source (the multicast sender) and the destination (the
multicast receiver) without fragmentation.
Bale et aL. Expires October 19, 2023 [Page 17]
Internet-Draft MSYNC April 17, 2023
3.7. Sending and Receiving MSYNC Objects
The following considerations are linked to the MSYNC sender and
MSYNC receiver configuration. Note that the configuration
procedure (protocol and format) is out of the scope of that
document.
3.7.1. Mapping over Transport Multicast Sessions
The mapping of MSYNC objects onto transport and IP multicast
sessions is not constrained by the MSYNC protocol but by the
multicast network capacity (i.e., the bandwidth) provisioned for
MSYNC as indicated in 2.3. For example, with xDSL, the capacity
dedicated to multicast is limited which may drive to an IP
multicast flow arrangement where one IP multicast session carries
the elements related to only one video sub-stream and another one
that carries the elements related to all audio sub-streams (each
of the audio sub-stream being associated with a different
transport multicast session). In that case, the MSYNC receiver
must join at most three IP multicast sessions (one for the video
representation packets, another one for the audio representations
packets and the last one for the control information).
Another arrangement could dedicate one IP multicast session per
HAS stream gathering all media sub-streams (one transport
multicast session per sub-stream).
Considering a satellite network, as all transport multicast
sessions are carried simultaneously, all IP multicast flow
arrangements may make sense. The MSYNC receiver may be instructed
to join all IP multicast sessions.
The MSYNC receiver is instructed to join the IP transport
multicast session corresponding to the sub-stream the application
(the HAS server in figure 1) must receive depending on the
incoming requests from the end user terminal/player. Generally
speaking the MSYNC receiver is instructed to join the IP multicast
stream associated with the content stream the application wants to
listen/receive.
Regarding the mapping onto a transport multicast session, the
triplet: source IP address (MSYNC supports Source Specific
Multicast), destination multicast IP address and destination
transport port number is the discriminator. It is RECOMMENDED to
carry media sub-streams and the MSYNC control information in
separate transport multicast sessions; it allows the deployment of
different error correction (see Section 3.9) or content protection
procedure (e.g., one ISP may decide to encrypt the transport
Bale et aL. Expires October 19, 2023 [Page 18]
Internet-Draft MSYNC April 17, 2023
multicast session dedicated to the transmission of control
information).
The following arrangement is typical in ADSL:
- One IP multicast session per media (audio or video or
subtitle) sub-stream (representation); each transport multicast
session having a different destination multicast IP address.
- One transport multicast session for the MSYNC control channel.
It is perfectly possible to send all the MSYNC packets in only
one transport multicast session and therefore one IP multicast
session.
For each MSYNC object (see object type in 3.2) to be sent over a
transport multicast session, the MSYNC sender MUST send the
following MSYNC packets in the specified order: one object info
packet, zero or more object info redundant packets, zero or more
HTTP header packets (in a sequential order) and zero, one or more
object data packets (or object data-part packets) in a sequential
order.
The MSYNC receiver MUST continuously control that it does respect
its MAX_BW_RECEIVE constraint (see Section 2.3) and therefore the
MSYNC receiver MUST NOT attempt to join a new IP multicast group
if that condition cannot be respected.
When the MSYNC object is a of size null (used to signal the end of
the transmission of a super object) then only one object info
packet is sent (see 3.2).
3.7.2. Detecting the End of an Object Reception
Detecting the end of an MSYNC object (or super object)
transmission is done thanks to the Object Info (see 3.2)
information. However, packet loss is possible and MSYNC packets
related to an MSYNC object may be received un-ordered. Packet re-
ordering may be acceptable or not depending on the deployment
scenario (it is generally bounded by the potential latency
introduced by un-ordered MSYNC packets reception). As a
consequence, the detection of the end of the MSYNC object
transmission MUST NOT be based solely on the detection of the
complete reception of the object.
An MSYNC receiver implementation MAY rely on a timer associated
with the maximum transmission time of a particular MSYNC object
type in order to detect the end of the MSYNC object transmission.
Bale et aL. Expires October 19, 2023 [Page 19]
Internet-Draft MSYNC April 17, 2023
The MSYNC receiver MAY arm a timer when the reception starts
(e.g., first received packet related to a new object) and MAY stop
the timer whenever the object is completely received. When the
timer reaches the time limit, the MSYNC receiver SHOULD consider
the transmission of that object done while the object being
partially received. Note that the MSYNC sender MAY use the same
maximum transmission time of a particular MSYNC object type for
controlling the object identifier (re-)allocation (see Section
3.1).
Assuming receiving unordered packets is not acceptable (i.e., not
possible), an MSYNC implementation MAY rely on the detection of a
new object transmission and decide that the previous object
transmission (and reception) is done while the object being
possibly partially received.
In the case of a partially received MSYNC object, this is up to
the application (e.g., the HAS server in Figure 2) to react,
triggering, for instance, an object repair procedure.
Note that packet repair and packet re-ordering can be performed at
the underlying RTP, based on the RTP sequence number (see Section
3.9).
3.7.3. Congestion Control
As indicated in Section 2.3, the MSYNC sender MUST control its
sending rate according to a pre-provisioned capacity (i.e.,
bandwidth) dedicated to MSYNC. However, the media bit-rate is not
always easy to compute. For example, the video bit-rate produced
by an encoder is theoretically constant but practically not really
and the bit-rate announced in the manifest for each media sub-
stream is typically an average bit-rate. Consequently, there is a
potential for a temporary congestion situation in the multicast
network and more probably in the last multicast sub-network (i.e.,
the one connected to the MSYNC receiver) advocating for a
receiver-driven congestion control method as detailed in Section
4.1 of [RFC8085].
The MSYNC receiver or more probably the Application exploiting the
MSYNC receiver may detect and mitigate the congestion. When a
congestion occurs, the received objects are subject to a growing
number of missing bytes and therefore a growing number of repair
procedures (when the MSYNC receiver repairs the packets based on
RTP - see 3.9). A possible mitigation action would consist for the
application to act as a circuit breaker as disclosed in [RFC8084];
sections 3.2.2 and 5.3 discuss the use case supported by MSYNC
related to pre-provisioned capacity. On a potential congestion
Bale et aL. Expires October 19, 2023 [Page 20]
Internet-Draft MSYNC April 17, 2023
detection, the MSYNC receiver, under the control of the
application, leaves one or more IP multicast group (and may even
stop completely the multicast reception). Regarding specifically
HAS streaming, one mitigation action would be to switch to a less
bandwidth consuming IP multicast session, forcing the end-user
terminal/player somehow to request HAS sub-stream elements related
to that less bandwidth consuming IP multicast session.
3.8. HAS Protocol Dependency
A certain number of MSYNC packet header fields have a dependency
on the HAS protocol and therefore on the manifest type. Similarly
the sending rules may also depend from the HAS protocol.
3.8.1. Object Info Packet
3.8.1.1. Media Sequence
The media sequence (an object Info Packet header field presented
in the Section 3.2) is used by the multicast gateway to
synchronize the MSYNC (i.e., multicast) reception with unicast
reception. The multicast gateway may operate jointly
MSYNC/multicast and unicast for retrieving HAS elements as
indicated in Section 2 and illustrated in figure 1. This is useful
in some occasions like processing a new streaming session request
(i.e., a manifest request after a channel switch) or in the case
of segment repair. The multicast gateway may attempt to retrieve a
manifest object or segment(s) through a unicast mean (e.g., a CDN
server or a repair server) in order to speed up the start of the
session or to repair damaged object(s). Consequently, the
multicast gateway needs to understand the freshness of the HAS
object received through multicast with regard to unicast.
If no unicast reception is used jointly with MSYNC in the
multicast gateway (e.g., like in one way delivery only), the
default value of 0x00 MAY be used.
If unicast reception is used jointly with MSYNC then the media
sequence MUST be set depending on the object type (Info Packet
header field presented in the Section 3.2.) as listed below.
HLS master playlist: 0x00
HLS variant playlist; MUST contain the value of EXT-X-MEDIA-SEQUENCE
added with the position in the playlist of the last segment
transmitted.
HLS segment: MUST contain the value of EXT-X-MEDIA-SEQUENCE added
Bale et aL. Expires October 19, 2023 [Page 21]
Internet-Draft MSYNC April 17, 2023
with the position of the segment in the playlist.
DASH manifest: MUST contain $time$/scale or $Number$ corresponding to
the last segment transmitted or under transmission (and possibly
received partially) and declared by the manifest.
DASH segment: MUST contain the $time$/scale or $Number$ value
3.8.1.2. Object URI
In the context of HTTP adaptive streaming, the object URI is a URI
reference.
If the object is a HAS addressable entity (e.g., a segment or a
CMAF chunk), the object URI MUST match (be a sub-string) with the
URL announced in the corresponding manifest/playlist.
Examples:
- The object URI: /tvChannel1/Q1/S_2 matches with the segment's
URL that is computed from the associated manifest/playlist:
".../tvChannel1/Q1/S_2.mp4"
- The object URI /tvChannel11/Q1/S_2_3 matches with the CMAF
chunk URL that is computed from the associated
manifest/playlist: ".../tvChannel11/Q1/S_2_3.mp4".
If the object is a non-addressable HAS entity (e.g., a HTTP/1.1
CTE block), the object URI is composed with a sub-string (that
MUST match with the URL announced in the corresponding manifest)
and a suffix composed with the hash sign/character (#) and the
block number).
Example:
- The object URI of the 3rd HTTP/1.1 CTE block of the segment
S_2: tvChannel11/Q1/S_2.mp4#2 matches with the segment's request
URL that terminates with ".../tvChannel1/Q1/S_2.mp4"
The block number of an object URI attached to a media data-part
object MUST be incremented for each subsequent transmission.
When all the MSYNC data-part packets for all the media data-part
objects (e.g., HTTP/1.1 CTE blocks) composing a super object
(e.g., a media segment) have been sent, the MSYNC sender MUST
signal the end of the MSYNC super object transmission through
sending an MSYNC object info packet with the object size set to
Bale et aL. Expires October 19, 2023 [Page 22]
Internet-Draft MSYNC April 17, 2023
zero (0). In addition, the object URI MUST contain the URI
reference of the next block (never transmitted). see Section 3.2.
Example:
- The object URI of the object info packet associated with the
1st HTTP/1.1 CTE block of the segment S_2:
tvChannel11/Q1/S_2.mp4#0
- The object URI of the object info packet associated with the
2nd HTTP/1.1 CTE block of the segment S_2:
tvChannel11/Q1/S_2.mp4#1
- The object URI of the object info packet associated with the
3rd HTTP/1.1 CTE block of the segment S_2:
tvChannel11/Q1/S_2.mp4#2
- The object URI of the object info packet associated with the
4st HTTP/1.1 CTE block of the segment S_2:
tvChannel11/Q1/S_2.mp4#3
- The object URI of the object info packet associated with the
5st HTTP/1.1 CTE block (of size null) signaling the end of the
super object (i.e., segment) transmission:
tvChannel11/Q1/S_2.m4s#4
3.8.2. Sending Rules
Whenever a manifest has to be sent over MSYNC, the following
applies.
- The corresponding MSYNC object data packets MUST be sent over
all the transport multicast sessions related to the transmission
of the media segments the manifest refers to.
- It MUST reference addressable objects (segment or CMAF chunk)
that have already been sent or for which the transmission has
started.
3.9. RTP as the Transport Multicast Session Protocol
RTP [RFC3550] MAY be used as part of the transport multicast
session protocol with the restrictions defined in Section 2 of
[RFC3551] according to the following.
- There is 0 contributing source identifier (CSRC).
- The timestamp is computed as indicated in [RFC3550]; it
Bale et aL. Expires October 19, 2023 [Page 23]
Internet-Draft MSYNC April 17, 2023
corresponds to the instant the MSYNC sender starts the MSYNC
packet transmission.
- The payload type (PT) MAY correspond to one of the values
specified in [RFC3551]. Its value should be communicated to the
MSYNC receiver as part of the MSYNC receiver configuration
through a separate unspecified mean.
- Each RTP multicast session MUST operate a unique different
SSRC number [RFC3550]. This allows packet retransmission (if
used) on the RTP transport multicast session basis.
- RTCP usage is not required.
Packet retransmission (see Figure 8 below) MAY be used in
association with the RTP multicast session for packet loss
recovery. If this is the case then the RTP Repair client and RTP
repair server MUST be compliant with [RFC4585], [RFC4588],
[RFC5506] and [RFC5761] according to the followings:
- The RTP Repair client (coupled to the MSYNC receiver) submits
transport layer feedback (FB) messages in NACK mode (Generic
NACK) to the RTP Repair Server according to [RFC5506] and
[RFC4585].
- The RTP Repair server receives, processes and responds to the
feedback NACK messages (FB) according to [RFC4588]. The RTP
Repair server MAY be located within the multicast server or it
MAY be hosted by any intermediate entity acting as a multicast
RTP receiver (i.e., capable of receiving the multicast RTP
packets). In any case, the RTP Repair server and the RTP Repair
client MUST operate a unicast interface.
- The Session-multiplexing scheme [RFC4588] MUST be applied: the
RTP retransmission (repair) stream MUST be sent on a different
RTP session than the original (multicast) RTP stream.
- The retransmission stream MUST support multiplexing the RTP
and RTCP traffic on a single port according to [RFC5761].
Bale et aL. Expires October 19, 2023 [Page 24]
Internet-Draft MSYNC April 17, 2023
Multicast server
+ ----------------- +
| HAS | MSYNC |
| Ingest | Sender |
+ ----------------- +
|
| + ------ +
multicast | RTP |
| ------->| Repair |
| | Server |
| + ------ +
V ^
+ ------------------------- + |
| HAS | MSYNC | RTP | <---
| | |Repair | unicast
| Server |Receiver |Client |
+ ------------------------- +
Multicast gateway
Figure 8: RTP repair
Note that instead of relying on "RTP retransmission", the MSYNC
receiver (i.e., the multicast gateway) could attempt to
recover/repair damaged HAS elements (e.g., segments, manifest)
through HTTP (aka "HTTP repair") and byte-range requests. However
the latter method requires a CDN, relies on HTTP Byte-range
request for which the support is not harmonized and is less
reactive than operating RTCP (UDP transactions over a dedicated
path are typically much quicker than HTTP/TCP transactions over
the unicast broadband data path).
Bale et aL. Expires October 19, 2023 [Page 25]
Internet-Draft MSYNC April 17, 2023
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
MSYNC is exposed to the risks linked to the underlying transport
protocols: UDP and RTP. An attacker can spoof the source and
destination addresses, modify any MSYNC headers and, because MSYNC
applies to IP multicast, the MSYNC sender has no control about the
MSYNC receivers which may represent a non-authorized party.
The multicast communication between the MSYNC sender and the MSYNC
receiver SHOULD be protected against confidentiality leaks,
message tampering and replay attacks. The MSYNC protocol does not
specify any security mechanism. MSYNC relies on possibly content
protection (Digital Right Management) and on the underlying
transport layer and security extensions for providing message
integrity, authentication and encryption. Secure RTP (SRTP)
[RFC3711] and IPsec applied to multicast [RFC5374] are potential
candidates for providing such extensions.
6. References
6.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997, <https://www.rfc-
editor.org/info/rfc2236>
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC
3550, July 2003, <https://www.rfc-
editor.org/info/rfc3550>.
[RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002, <https://www.rfc-
editor.org/info/rfc3376>
[RFC5506] I. Johansson, M. Westerlund. "Support for Reduced-Size
Real-Time Transport Control Protocol(RTCP): Opportunities
and Consequences", RFC 5506, April 2009, <https://www.rfc-
Bale et aL. Expires October 19, 2023 [Page 26]
Internet-Draft MSYNC April 17, 2023
editor.org/info/rfc5506>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>.
[RFC9112] R. T. Fielding, M. Nottingham, J. Reschke, " HTTP/1.1", RFC
9112, June 2022, <https://www.rfc-
editor.org/info/rfc9112>.
[MPEGCMAF] "Information technology - Multimedia application format
(MPEG-A) - Part 19: Common media application format (CMAF)
for segmented media", ISO/IEC 23000-19
[MPEGDASH] "Information technology - Dynamic adaptive streaming over
HTTP (DASH) - Part1: Media presentation description and
segment formats", ISO/IEC23009-1
6.2. Informative References
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", RFC 3551, July
2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman.
"The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004, <https://www.rfc-
editor.org/info/rfc3711>.
[RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations
for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Snooping Switches", RFC
4585, July 2006, <https://www.rfc-editor.org/info/rfc4541>
[RFC4585] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey.
"Extended RTP Profile for Real-time Transport Control
Protocol(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC5374] B. Weis, G. Gross, D. Ignjatic. "Multicast Extensions to
the Security Architecture for the Internet Protocol", RFC
5374, November 2008, <https://www.rfc-
Bale et aL. Expires October 19, 2023 [Page 27]
Internet-Draft MSYNC April 17, 2023
editor.org/info/rfc5374>.
[RFC6770] G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma,
G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012
[RFC7336] L. Peterson, B. Davie, R. van Brandenburg, "Framework for
Content Distribution Network Interconnection (CDNI)", RFC
7336, August 2014
[RFC8084] G. Fairhurst, "Network Transport Circuit Breakers", RFC
8084, March 2017
[RFC8085] L. Eggert, G. Fairhurst, G. Shepherd, "UDP Usage
Guidelines", RFC 8085, March 2017
[RFC8216] R. Pantos, Ed., W. May, "HTTP Live Streaming", RFC 8216,
August 2017, <https://www.rfc-editor.org/info/rfc8216>.
7. Acknowledgments
The authors will be ever grateful to their late colleague Arnaud
Leclerc who has been the initiator of that work.
The authors would like to thank the following people for their
feedback: Yann Barateau (Eutelsat).
8. Change Log
-11: Another round of grammatical/orthographical errors
correction. Clarified the Figures 1 and 2 regarding the
directional media flows, adding a statement in the introduction
about multicast and capacity planning
- 10: Introduced sub-sections in Section 2 allowing to describe
the multicast network assumptions and in particular related to
congestion avoidance (pre-provisioning the bandwidth resources) .
Similarly introduced new sub-sections in Section 3.7 for
describing congestion control. Performed several minor editorial
corrections. Corrected the new mtype value associated with the
media HS playlist.
- 09: new set of editorial/clarification changes. Added a new
mtype value (Section 3.2) for differentiating master and media HLS
playlist backward compatible.
- 08: Another round of editorial changes
Bale et aL. Expires October 19, 2023 [Page 28]
Internet-Draft MSYNC April 17, 2023
- 07: Lots of editorial changes
- 06: Example in Section 3.8.1.2. update the example for using the
"#" character as the bloc number prefix instead of the "_"
character.
- 05: Updated Section 3.9 adding reference (RFC4588) and details
for RTP retransmission. Updated/normalized references in Section
5.1 and Section 5.2.
- 04: Added detection of super object transmission (Section 3.2
and Section 3.8.1.2); several adjustments regarding RFC style;
Section numbering correction.(Sections 3.9 and 3.10 are now
Sections 3.8 and 3.9 respectively).
Authors' Addresses
Sophie Bale
Broadpeak
15 rue Claude Chappe
Zone des Champs Blancs
35510 Cesson-Sevigne
France
Email: sophie.bale@broadpeak.tv
Remy Brebion
Broadpeak
15 rue Claude Chappe
Zone des Champs Blancs
35510 Cesson-Sevigne
France
Email: remy.brebion@broadpeak.tv
Guillaume Bichot (Editor)
Broadpeak
15 rue Claude Chappe
Zone des Champs Blancs
35510 Cesson-Sevigne
France
Email: guillaume.bichot@broadpeak.tv
Bale et aL. Expires October 19, 2023 [Page 29]