rfc9706v2.txt   rfc9706.txt 
skipping to change at line 16 skipping to change at line 16
R. Adam R. Adam
GEANT GEANT
December 2024 December 2024
TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to
Mass Audiences Mass Audiences
Abstract Abstract
As Internet audience sizes for high-interest live events reach As Internet audience sizes for high-interest live events reach
unprecedented levels and bitrates climb to support 4K/8K Augmented unprecedented levels and bitrates climb to support 4K /8K / Augmented
Reality (AR), live streaming can place a unique type of stress upon Reality (AR), live streaming can place a unique type of stress upon
network resources. TreeDN is a tree-based Content Delivery Network network resources. TreeDN is a tree-based Content Delivery Network
(CDN) architecture designed to address the distinctive scaling (CDN) architecture designed to address the distinctive scaling
challenges of live streaming to mass audiences. TreeDN enables challenges of live streaming to mass audiences. TreeDN enables
operators to offer Replication-as-a-Service (RaaS) at a fraction of operators to offer Replication-as-a-Service (RaaS) at a fraction of
the cost of traditional, unicast-based CDNs; in some cases, there is the cost of traditional, unicast-based CDNs -- in some cases, there
no additional cost to the infrastructure. In addition to efficiently is no additional cost to the infrastructure. In addition to
utilizing network resources to deliver existing multi-destination efficiently utilizing network resources to deliver existing multi-
traffic, this architecture also enables new types of content and use destination traffic, this architecture also enables new types of
cases that previously were not possible or economically viable using content and use cases that previously were not possible or
traditional CDN approaches. Finally, TreeDN is a decentralized economically viable using traditional CDN approaches. Finally,
architecture and a democratizing technology that makes content TreeDN is a decentralized architecture and a democratizing technology
distribution more accessible to more people by dramatically reducing that makes content distribution more accessible to more people by
the costs of replication. dramatically reducing the costs of replication.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 94 skipping to change at line 94
14. References 14. References
14.1. Normative References 14.1. Normative References
14.2. Informative References 14.2. Informative References
Appendix A. Netverses Appendix A. Netverses
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
As Internet audience sizes for high-interest live events reach As Internet audience sizes for high-interest live events reach
unprecedented levels and bitrates climb to support 4K/8K Augmented unprecedented levels and bitrates climb to support 4K / 8K /
Reality (AR), live streaming can place a unique type of stress upon Augmented Reality (AR), live streaming can place a unique type of
network resources. TreeDN is a tree-based Content Delivery Network stress upon network resources. TreeDN is a tree-based Content
(CDN) architecture designed to address the distinctive scaling Delivery Network (CDN) architecture designed to address the
challenges of live streaming to mass audiences. TreeDN enables distinctive scaling challenges of live streaming to mass audiences.
operators to offer Replication-as-a-Service (RaaS) at a fraction of TreeDN enables operators to offer Replication-as-a-Service (RaaS) at
the cost of traditional, unicast-based CDNs; in some cases, there is a fraction of the cost of traditional, unicast-based CDNs; in some
no additional cost to the infrastructure. In addition to efficiently cases, there is no additional cost to the infrastructure. In
utilizing network resources to deliver existing multi-destination addition to efficiently utilizing network resources to deliver
traffic, this architecture also enables new types of content and use existing multi-destination traffic, this architecture also enables
cases that previously were not possible or economically viable using new types of content and use cases that previously were not possible
traditional CDN approaches. Finally, TreeDN is a decentralized or economically viable using traditional CDN approaches. Finally,
architecture and a democratizing technology that makes content TreeDN is a decentralized architecture and a democratizing technology
distribution more accessible to more people by dramatically reducing that makes content distribution more accessible to more people by
the costs of replication. dramatically reducing the costs of replication.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Problem Statement 3. Problem Statement
skipping to change at line 194 skipping to change at line 194
efficiently by the network. efficiently by the network.
5. Multicast Challenges in the Past 5. Multicast Challenges in the Past
The following issues have been some of the primary challenges for The following issues have been some of the primary challenges for
deployment of IP multicast over the global Internet. This is not deployment of IP multicast over the global Internet. This is not
intended to be an exhaustive list but rather a list that provides intended to be an exhaustive list but rather a list that provides
context for the solution and how it addresses these primary context for the solution and how it addresses these primary
challenges. challenges.
The "All or Nothing" problem: IP multicast requires every Layer 3 * The "All or Nothing" problem: IP multicast requires every Layer 3
hop between the source and receivers to be multicast enabled. To hop between the source and receivers to be multicast enabled. To
achieve ubiquitous availability on the global Internet, this achieve ubiquitous availability on the global Internet, this
essentially means that nearly every interface on every router and essentially means that nearly every interface on every router and
firewall between all end hosts must support a multicast routing firewall between all end hosts must support a multicast routing
protocol (such as Protocol Independent Multicast - Sparse Mode protocol (such as Protocol Independent Multicast - Sparse Mode
(PIM-SM) [RFC7761] or the Multipoint Label Distribution Protocol (PIM-SM) [RFC7761] or the Multipoint Label Distribution Protocol
(mLDP) [RFC6388]). This requirement creates a bar to deployment (mLDP) [RFC6388]). This requirement creates a bar to deployment
that is practically impossible to overcome. that is practically impossible to overcome.
The "It's Too Complex" problem: Operators have long complained that * The "It's Too Complex" problem: Operators have long complained
multicast routing protocols like PIM-SM are simply too complex, that multicast routing protocols like PIM-SM are simply too
making it costly to design, configure, manage, and troubleshoot IP complex, making it costly to design, configure, manage, and
multicast in the network. troubleshoot IP multicast in the network.
The "Chicken and Egg" problem: There's not much multicast content * The "Chicken and Egg" problem: There's not much multicast content
because there's not much of a multicast-enabled audience, but because there's not much of a multicast-enabled audience, but
there's not much of a multicast-enabled audience because there's there's not much of a multicast-enabled audience because there's
not much multicast content. not much multicast content.
TreeDN is the evolution of network-based replication based on lessons TreeDN is the evolution of network-based replication based on lessons
learned over decades and is designed to address the problems listed learned over decades and is designed to address the problems listed
above. above.
6. TreeDN Architecture 6. TreeDN Architecture
skipping to change at line 263 skipping to change at line 263
One overlay technology that TreeDN leverages is Automatic Multicast One overlay technology that TreeDN leverages is Automatic Multicast
Tunneling (AMT) [RFC7450]. With AMT, end hosts on unicast-only Tunneling (AMT) [RFC7450]. With AMT, end hosts on unicast-only
networks (AMT Gateways) can dynamically build tunnels to routers on networks (AMT Gateways) can dynamically build tunnels to routers on
the multicast-enabled part of the network (AMT Relays) and receive the multicast-enabled part of the network (AMT Relays) and receive
multicast streams. The AMT Gateway is a thin software client that multicast streams. The AMT Gateway is a thin software client that
typically sits on the receiving end host and initiates the tunnel at typically sits on the receiving end host and initiates the tunnel at
an AMT Relay. The AMT Relay is a tunnel server that typically sits an AMT Relay. The AMT Relay is a tunnel server that typically sits
at the border of the multicast network. AMT allows any end host on at the border of the multicast network. AMT allows any end host on
the Internet to receive multicast content regardless of whether their the Internet to receive multicast content regardless of whether their
local provider supports multicast (aka, "off-net receivers"); this local provider supports multicast (aka, "off-net receivers"), which
addresses the "All or Nothing" problem. Links and devices that do addresses the "All or Nothing" problem. Links and devices that do
not support multicast are simply tunneled over; they no longer not support multicast are simply tunneled over -- they no longer
present a barrier to the overall replication service for end users. present a barrier to the overall replication service for end users.
Those networks that do deploy and support multicast, as well as the Those networks that do deploy and support multicast, as well as the
content providers that serve up multicast content, are able to enjoy content providers that serve up multicast content, are able to enjoy
the benefits of efficient replication and delivery. Further, these the benefits of efficient replication and delivery. Further, these
benefits can serve as incentives for operators who do not yet support benefits can serve as incentives for operators who do not yet support
multicast to enable it on their networks, which is a key benefit of multicast to enable it on their networks, which is a key benefit of
incremental deployment described in Section 4.3 of [RFC9049]. Once incremental deployment described in Section 4.3 of [RFC9049]. Once
the cost of carrying duplicated unicast tunnels is perceived by those the cost of carrying duplicated unicast tunnels is perceived by those
operators to exceed the cost of deploying multicast, they are more operators to exceed the cost of deploying multicast, they are more
likely to enable multicast on their networks. Thus, TreeDN likely to enable multicast on their networks. Thus, TreeDN
skipping to change at line 301 skipping to change at line 301
that do not support multicast. that do not support multicast.
6.2. TreeDN Native On-Net 6.2. TreeDN Native On-Net
Networks that support multicast provide the native on-net component Networks that support multicast provide the native on-net component
of TreeDN. The primary requirement of the native on-net component is of TreeDN. The primary requirement of the native on-net component is
to support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which to support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which
is merely a subset of PIM-SM, is the multicast routing protocol is merely a subset of PIM-SM, is the multicast routing protocol
typically used in SSM. However, any multicast routing protocol typically used in SSM. However, any multicast routing protocol
capable of supporting SSM can be used in the TreeDN native on-net capable of supporting SSM can be used in the TreeDN native on-net
component, such as mLDP, Global Table Multicast (GTM) [RFC7716] and component, such as mLDP, Global Table Multicast (GTM) [RFC7716], BGP-
BGP-based Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP- based Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN)
MVPN) [RFC6513] for those operators who carry the global routing [RFC6513] for those operators who carry the global routing table in a
table in a Virtual Routing and Forwarding (VRF) table. Likewise, any Virtual Routing and Forwarding (VRF) table. Likewise, any data plane
data plane technology that supports SSM, including Bit Index Explicit technology that supports SSM, including Bit Index Explicit
Replication (BIER) [RFC8279] and Segment Routing (SR) Point-to- Replication (BIER) [RFC8279] and Segment Routing (SR) Point-to-
Multipoint (P2MP) [RFC9524], can be used. Multipoint (P2MP) [RFC9524], can be used.
The key benefit of SSM as the native on-net component of TreeDN is The key benefit of SSM as the native on-net component of TreeDN is
that it radically simplifies the control plane needed to support that it radically simplifies the control plane needed to support
replication in the network. This simplification comes by moving replication in the network. This simplification comes by moving
source discovery from the network layer to some sort of out-of-band source discovery from the network layer to some sort of out-of-band
mechanism, usually in the application layer. In SSM, the receiver mechanism, usually in the application layer. In SSM, the receiver
uses the Internet Group Management Protocol Version 3 (IGMPv3) uses the Internet Group Management Protocol Version 3 (IGMPv3)
[RFC3376] for IPv4 or the Multicast Listener Discovery Version 2 [RFC3376] for IPv4 or the Multicast Listener Discovery Version 2
(MLDv2) protocol [RFC3810] for IPv6 to specify both the source and (MLDv2) protocol [RFC3810] for IPv6 to specify both the source and
group address of the multicast stream. This allows the last-hop group address of the multicast stream. This allows the last-hop
router to immediately join the multicast stream along the shortest- router to immediately join the multicast stream along the shortest-
path tree (SPT) without the need for shared trees. This benefit path tree (SPT) without the need for shared trees. This benefit
addresses the "It's Too Complex" problem. By eliminating the need addresses the "It's Too Complex" problem. By eliminating the need
for network-based source discovery, most of the complexity of for network-based source discovery, most of the complexity of
multicast is then eliminated, which reduces the cost of deploying and multicast is then eliminated, which reduces the cost of deploying and
operating a multicast network. Further rationale for this SSM-only operating a multicast network. Further rationale for this SSM-only
approach can be found in Any-Source Multicast (ASM) deprecation approach can be found in Any-Source Multicast (ASM) Deprecation
[RFC8815]. [RFC8815].
7. Replication-as-a-Service (RaaS) 7. Replication-as-a-Service (RaaS)
Content providers have traditionally used CDNs to distribute content Content providers have traditionally used CDNs to distribute content
that needs to be delivered to large audiences, essentially that needs to be delivered to large audiences, essentially
outsourcing the task of replication to CDN providers. Most CDNs outsourcing the task of replication to CDN providers. Most CDNs
utilize unicast delivery, as multicast is not an option due to its utilize unicast delivery, as multicast is not an option due to its
lack of general availability on the global Internet. TreeDN is a CDN lack of general availability on the global Internet. TreeDN is a CDN
architecture that leverages tree-based replication to more architecture that leverages tree-based replication to more
skipping to change at line 369 skipping to change at line 369
accounting data (e.g., traffic data, number of AMT tunnels, etc.) to accounting data (e.g., traffic data, number of AMT tunnels, etc.) to
properly bill customers for the service. By contrast, traditional properly bill customers for the service. By contrast, traditional
unicast-based CDNs often incorporate proprietary, non-interoperable unicast-based CDNs often incorporate proprietary, non-interoperable
technologies and require significant coordination between the content technologies and require significant coordination between the content
provider and the CDN to handle such things as file storage, data provider and the CDN to handle such things as file storage, data
protection, and key management. protection, and key management.
TreeDN introduces a deployment model that requires new considerations TreeDN introduces a deployment model that requires new considerations
for transport-layer mechanisms that are frequently relied upon by for transport-layer mechanisms that are frequently relied upon by
traditional unicast-based CDNs. A discussion on these considerations traditional unicast-based CDNs. A discussion on these considerations
and differences can be found in Section 8. and differences can be found in Section 9.
8. Decentralization/Democratization of Content Sourcing 8. Decentralization/Democratization of Content Sourcing
TreeDN is an inherently decentralized architecture. This reduces the TreeDN is an inherently decentralized architecture. This reduces the
cost for content sourcing, as any host connected to a multicast- cost for content sourcing, as any host connected to a multicast-
enabled network or on a source-capable overlay can send out a single enabled network or on a source-capable overlay can send out a single
data stream that can be reached by an arbitrarily large audience. By data stream that can be reached by an arbitrarily large audience. By
effectively reducing the marginal cost of reaching each additional effectively reducing the marginal cost of reaching each additional
audience member to zero, from the perspective of the source, TreeDN audience member to zero, from the perspective of the source, TreeDN
democratizes content sourcing on the Internet. democratizes content sourcing on the Internet.
skipping to change at line 479 skipping to change at line 479
changes. EUMETCast Terrestrial connects to the GEANT network, which changes. EUMETCast Terrestrial connects to the GEANT network, which
provides TreeDN services to deliver this real-time data natively to provides TreeDN services to deliver this real-time data natively to
end users on multicast-enabled networks and to end users on unicast- end users on multicast-enabled networks and to end users on unicast-
only networks via a global deployment of AMT relays. Details of the only networks via a global deployment of AMT relays. Details of the
EUMETCast Terrestrial service over the GEANT TreeDN network are EUMETCast Terrestrial service over the GEANT TreeDN network are
described in [EUMETCast-TERRESTRIAL-AMT]. Additional details on how described in [EUMETCast-TERRESTRIAL-AMT]. Additional details on how
this deployment uses encryption, authorization, reliability, and this deployment uses encryption, authorization, reliability, and
unicast feedback channels for end-to-end file delivery monitoring can unicast feedback channels for end-to-end file delivery monitoring can
be found in [EUMETSAT-TERRESTRIAL]. be found in [EUMETSAT-TERRESTRIAL].
The Multicast Menu is a web-based portal that can list and launch The Multicast Menu [Multicast-Menu] is a web-based portal that can
active multicast streams that are available on a global TreeDN list and launch active multicast streams that are available on a
network of various research and education networks. Details of this global TreeDN network of various research and education networks.
TreeDN network, as well as the Multicast Menu, are described in Details of this TreeDN network, as well as the Multicast Menu, are
[Multicast-Menu]. described in [Offnet-Sourcing-Multicast-Menu].
The RARE network is a global testbed interconnecting several National The RARE network is a global testbed interconnecting several National
Research and Education Networks (NRENs) via routers running BIER. Research and Education Networks (NRENs) via routers running BIER.
AMT relays are deployed to deliver multicast traffic from sources on AMT relays are deployed to deliver multicast traffic from sources on
the RARE network to receivers on unicast-only networks across the the RARE network to receivers on unicast-only networks across the
Internet. Details of the RARE network are described in Internet. Details of the RARE network are described in
[BIER-AMT-Deployment]. [BIER-AMT-Deployment].
11. Operational Considerations 11. Operational Considerations
skipping to change at line 643 skipping to change at line 643
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme- <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-18>. g-ikev2-18>.
[MAUD] Nilsson, M. E., Turnbull, R. S., Stevens, T. S., and S. [MAUD] Nilsson, M. E., Turnbull, R. S., Stevens, T. S., and S.
Appleby, "Multicast-Assisted Unicast Delivery", IBC2023 Appleby, "Multicast-Assisted Unicast Delivery", IBC2023
Tech Papers, September 2023, <https://www.ibc.org/ Tech Papers, September 2023, <https://www.ibc.org/
technical-papers/ibc2023-tech-papers-multicast-assisted- technical-papers/ibc2023-tech-papers-multicast-assisted-
unicast-delivery/10235.article>. unicast-delivery/10235.article>.
[Multicast-Menu] [Multicast-Menu]
"Multicast Menu", <https://menu.treedn.net>.
[Offnet-Sourcing-Multicast-Menu]
Delwiche, L., "Offnet Sourcing with the Multicast Menu", Delwiche, L., "Offnet Sourcing with the Multicast Menu",
IETF 114 Proceedings, July 2022, IETF 114 Proceedings, July 2022,
<https://datatracker.ietf.org/meeting/114/materials/ <https://datatracker.ietf.org/meeting/114/materials/
slides-114-mboned-offnet-sourcing-with-the-multicast-menu- slides-114-mboned-offnet-sourcing-with-the-multicast-menu-
01>. 01>.
[QUIC-Multicast] [QUIC-Multicast]
Holland, J., Pardue, L., and M. Franke, "Multicast Holland, J., Pardue, L., and M. Franke, "Multicast
Extension for QUIC", Work in Progress, Internet-Draft, Extension for QUIC", Work in Progress, Internet-Draft,
draft-jholland-quic-multicast-05, 7 July 2024, draft-jholland-quic-multicast-05, 7 July 2024,
 End of changes. 13 change blocks. 
45 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48.