Internet DRAFT - draft-shi-moq-design-space-analysis-of-moq
draft-shi-moq-design-space-analysis-of-moq
Media Over QUIC H. Shi, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational Y. Cui
Expires: 5 September 2024 Tsinghua University
X. Yu
Alibaba Group
4 March 2024
Design Space Analysis of MoQ
draft-shi-moq-design-space-analysis-of-moq-03
Abstract
This document investigates potential solution directions within the
charter scope of MoQ WG. MoQ aims to provide low-latency, efficient
media delivery solution for use cases including live streaming,
gaming and video conferencing. To achieve low-latency media transfer
efficiently, the network topology of relay nodes and the computation
done at the relay nodes should be considered carefully. This
document provides the analysis of those factors which can help the
design of the MoQ protocols.
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://VMatrix1900.github.io/draft-moq-design-space-analysis-of-moq/
draft-shi-moq-design-space-analysis-of-moq.html. Status information
for this document may be found at https://datatracker.ietf.org/doc/
draft-shi-moq-design-space-analysis-of-moq/.
Discussion of this document takes place on the Media Over QUIC
Working Group mailing list (mailto:moq@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
Source for this draft and an issue tracker can be found at
https://github.com/VMatrix1900/draft-moq-design-space-analysis-of-
moq.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Shi, et al. Expires 5 September 2024 [Page 1]
Internet-Draft MoQ Design Space March 2024
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 5 September 2024.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Design Choice 1: Static Tree Topology versus Dynamic Mesh
Topology . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Choice 2: QUIC hop-by-hop versus end-to-end . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Media over QUIC aims to provide low-latency, efficient media delivery
solution for use cases including live streaming, gaming, and video
conferencing. The latency requirement and the transmission pattern
are analyzed in [moq-req]. To scale efficiently, relay can be used
to optimize the delivery performance by caching, selective dropping,
etc. However, how to accomplish that remains unclear. Lots of
Shi, et al. Expires 5 September 2024 [Page 2]
Internet-Draft MoQ Design Space March 2024
factors of the relay and protocol design choice can affect the
performance gain of leveraging relay. This document aims to provide
analysis of those design choices.
2. Terminology
* Relay: An element which participates in the forwarding of the
media content. Possibly support caching, selective dropping to
optimize the media transmission performance.
* Producer: An endpoint which generate the media stream. Could be
the original content producer (a live streaming uploader) or the
re-encoder in the cloud.
* Consumer: An endpoint which receive the media stream. Could be
the live stream viewer or the re-encoder in the cloud.
2.1. Requirements Language
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.
3. Design Choice 1: Static Tree Topology versus Dynamic Mesh Topology
The first question of using relay to forward the media between the
producer and the consumer is the topology of relays. In traditional
CDN network, each CDN site can be viewed as a relay. Those relays
are organized in a tree (see Figure 1). The producer and the
consumer are usually connected to the edge node of the CDN which is
the leaf node in the tree. In this case, the path for media in live
streaming is usually producer - edge node 1 (relay 1) - parent node 1
(relay 2) - origin node (relay 3) - parent node 2 (relay 4) - edge
node 2 (relay 5) - consumer, i.e. the media need to first go up to
the root of the tree, then go down to another leaf node, traversing
multiple (at least 3) relays if the CDN hierarchy is deep or the
producer and the consumer is highly distributed. The tree topology
is simple to build since the path of the stream is fixed and the leaf
node can be lightweight and deployed closely to user. The computing
intensive process can be put in the much more powerful root servers.
[QUICR-arch] is similar to the tree topology of CDN with one
improvement: the relay can shortcut the media transmission. If the
producer and the consumer share a parent relay, the media will be
forwarded in the relay instead of the root of the tree (called Origin
in QUICR's term).
Shi, et al. Expires 5 September 2024 [Page 3]
Internet-Draft MoQ Design Space March 2024
+----------+
+----------->| Root +-----------+
| +----------+ |
| |
+----+-----+ +----v-----+
+----->| Parent-1 | | Parent-2 +--------+
| +----------+ +----------+ |
| |
+----+-----+ +----v-----+
| Edge-1 | | Edge-2 |
+----^-----+ +----------+
| |
| |
+-----+----+ +---v------+
| Producer | | Consumer |
+----------+ +----------+
Figure 1: static tree topology
Another approach is to connect the relays in a dynamic mesh instead
of a static hierarchy. Alibaba's low-latency live streaming network
builds on a flat CDN overlay [LiveNet]. A centralized controller
collects the latency between each relay periodically and calculates
the optimal path (latency-wise) for each media stream dynamically.
Alibaba claims the flat topology reduce the latency by half compared
to static hierarchy. An example is shown in Figure 2, the media
stream is forwarded through relay 1 and relay 4, only 2 hops. If the
network path between relay 1 and relay 4 are congested, relay 1 -
relay 2/3 - relay 4 maybe used to provide lower-latency forwarding.
The controller can be connected with 3rd party application provider
and manages the interactive media communication between producer and
consumer for the application provider. The interactive media can be
delivered to other consumers via certain relays of the live streaming
network. A request of interactive media communication can be
triggered by a consumer. The request is sent to the application
provider which then attempts to pull related media of corresponding
consumer and producer from the live streaming network. The
application provider merges the media containing the producer and the
consumer and delivers the merged media to the live streaming network.
The live steaming network conducts the media switching for the
corresponding producer, consumer and other consumers via the
corresponding relays upon the receipt of the media switching request.
Shi, et al. Expires 5 September 2024 [Page 4]
Internet-Draft MoQ Design Space March 2024
+-----------------------------------------+
| Controller |
+-----------------------------------------+
| |
| +---------+ |
| +-------> Relay-2 +---------+ |
| | +----+----+ path 2 | |
| | | | |
+----------+ | +----+----+ | +----v----+ | +----------+
| Producer +--+>| Relay-1 +-------+---------> Relay-4 +-+-->| Consumer |
+----------+ | +----+----+ | path 1 +---------+ | +----------+
| | | | |
| | | | |
| | +----+----+ | |
| +-------+ Relay-3 +---------+ |
| +---------+ |
| |
+-----------------------------------------+
Figure 2: dynamic mesh topology
4. Design Choice 2: QUIC hop-by-hop versus end-to-end
The media flow sending from the producer to the consumer will go
through several relays. The media content will be encrypted using
QUIC encryption as requested in charter. But whether the relay node
will terminate the QUIC connection remains open. There are following
two options to implement the MoQ protocol stack.
The first option is to running the entire MoQ protocol inside QUIC
encryption, including the media metadata which is needed by relay
(see Figure 3). Thus the relay has to terminate the QUIC connection,
decrypting the QUIC payload. This will require each relay node hold
a valid CA certificate and run the CA verification process. Just
like what the CDN node does nowadays.
Media (Metadata + Content)
----------------------------------------------
Protocol header | Protocol payload <-------- MoQ
----------------------------------------------
QUIC <-------- Transport
Figure 3: MoQ running over QUIC, like HTTP
The second option is to only encrypt the media content using QUIC
encryption but leave the metadata to other mechanism (see Figure 4).
In this way, the QUIC connection is from producer to consumer. The
relay does not need to decrypt the QUIC, saving the computing power.
Shi, et al. Expires 5 September 2024 [Page 5]
Internet-Draft MoQ Design Space March 2024
As the charter put it: "Even when media content is end-to-end
encrypted, the relays can access metadata. Hence a new mechanism to
convey the metadata to the relay is needed, similar to SDP for RTP,
or m3u8 file for HLS.
Media metadata | Media content <-----\
-------------------------|----------------------- \
Protocol header | Protocol payload <------ MoQ
-------------------------|----------------------- /
Other | QUIC <-----/
Figure 4: MoQ using QUIC for media, other for metadata, like WebRTC
5. Security Considerations
When the metadata is not carried inside the QUIC payload, it should
be protected from unauthorized third-part access to to protect the
privacy. Relay should be authenticated to access the metadata.
6. References
6.1. Normative References
[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>.
6.2. Informative References
[LiveNet] "LiveNet - A Low-Latency Video Transport Network", October
2022,
<https://dl.acm.org/doi/abs/10.1145/3544216.3544236>.
[moq-req] Gruessing, J. and S. Dawkins, "Media Over QUIC - Use Cases
and Requirements for Media Transport Protocol Design",
Work in Progress, Internet-Draft, draft-ietf-moq-
requirements-02, 29 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
requirements-02>.
Shi, et al. Expires 5 September 2024 [Page 6]
Internet-Draft MoQ Design Space March 2024
[QUICR-arch]
Jennings, C. and S. Nandakumar, "QuicR - Media Delivery
Protocol over QUIC", October 2022,
<https://datatracker.ietf.org/doc/draft-jennings-moq-
quicr-arch/>.
Authors' Addresses
Hang Shi (editor)
Huawei Technologies
China
Email: shihang9@huawei.com
Yong Cui
Tsinghua University
China
Email: cuiyong@tsinghua.edu.cn
Xiaobo Yu
Alibaba Group
China
Email: shibo.yxb@alibaba-inc.com
Shi, et al. Expires 5 September 2024 [Page 7]
