RFC 6707

Content Distribution Network Interconnection (CDNI) Problem Statement

📅 published September 2012, from ietf

Content Distribution Network Interconnection (CDNI) Problem Statement 🎀

RFC number: 6707 Category: Informational (not a Standards Track spec, just here to share info) 📚 Date: September 2012 ISSN: 2070-1721 Authors: B. Niven-Jenkins (Velocix, Alcatel-Lucent), F. Le Faucheur (Cisco), and N. Bitar (Verizon) 💅 Obsoletes / Updates: This document doesn't list any RFCs it obsoletes or updates. 🙈

Abstract ✨

Okay so, Content Delivery Networks (CDNs) are literally amazing for cacheable content 💖. You get lower delivery cost, a better quality of experience for End Users, and more robust delivery. That's why they get used so much for large-scale content delivery 🌈. So existing CDN Providers are scaling up their infrastructure, and a bunch of Network Service Providers (NSPs) are building their own CDNs too. 🚀

It's generally desirable that a given content item can reach an End User no matter where that End User is or what network they're attached to 🦋. That's the whole reason we want to hook standalone CDNs together so they can work as one open content delivery infrastructure. That way content can flow end-to-end from Content Service Providers (CSPs) to End Users 🫶. The tea, though? There are currently no standards or open specs that make this CDN Interconnection happen 😭.

This document's goal is to lay out the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group 🧚.

Status of This Memo ⭐

This document is not an Internet Standards Track specification. It's published just for informational purposes, so no pressure 🍓.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every document the IESG approves is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 💅.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6707 🔗.

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) as they were in effect on the date this document was published. Please actually read these documents carefully, because 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 they're provided without warranty as described in the Simplified BSD License 📜.

Table of Contents 🗂️

1. Introduction ....................................................3
   1.1. Terminology ................................................4
   1.2. CDN Background .............................................9
2. CDN Interconnection Use Cases ...................................9
3. CDN Interconnection Model and Problem Area for IETF ............11
4. Scoping the CDNI Problem .......................................15
   4.1. CDNI Control Interface ....................................16
   4.2. CDNI Request Routing Interface ............................16
   4.3. CDNI Metadata Interface ...................................17
   4.4. CDNI Logging Interface ....................................17
5. Security Considerations ........................................17
   5.1. Security of the CDNI Control Interface ....................18
   5.2. Security of the CDNI Request Routing Interface ............18
   5.3. Security of the CDNI Metadata Interface ...................19
   5.4. Security of the CDNI Logging Interface ....................19
6. Acknowledgements ...............................................19
7. Informative References .........................................20
Appendix A. Design Considerations for Realizing the CDNI
            Interfaces ............................................22
  A.1. CDNI Control Interface .....................................22
  A.2. CDNI Request Routing Interface .............................23
  A.3. CDNI Metadata Interface ....................................25
  A.4. CDNI Logging Interface .....................................26
Appendix B. Additional Material ...................................27
  B.1. Non-Goals for IETF .........................................27
  B.2. Relationship to Relevant IETF Working Groups and IRTF
       Research Groups ............................................29
    B.2.1. ALTO WG ................................................29
    B.2.2. DECADE WG ..............................................29
    B.2.3. PPSP WG ................................................31
    B.2.4. IRTF P2P Research Group ................................31

1. Introduction ✨

The amount of video and multimedia content going over the Internet is growing super fast, and it's expected to keep growing 📈. With all that growth, CDNs are giving us a lot: reduced delivery cost, improved quality of experience for End Users (EUs), and increased robustness of delivery 💖. That's why CDNs get used so much for large-scale content delivery. Existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs 🚀.

It's generally desirable that a given content item can reach an EU no matter where that EU is or what network they're attached to 🌸. But here's the catch: a CDN in charge of delivering some content might not have a footprint that reaches close enough to the EU's current location or attachment network. It also might not have the resources it needs to give users the experience and cost benefits that a more distributed CDN infrastructure would allow 😭. So the motivation is to interconnect standalone CDNs, so their combined footprint and resources can be leveraged for end-to-end delivery of content from CSPs to EUs 🫶. For example, a CSP could contract with an "authoritative" CDN Provider to deliver its content, and then that Authoritative CDN Provider could contract with one or more downstream CDN Providers to distribute and deliver some or all of the content on its behalf 🦋.

A typical end-to-end content delivery scenario would involve these business arrangements:

  • A business arrangement between the EU and his CSP, which authorizes the EU to access content items the CSP controls.
  • A business arrangement between the CSP and an "authoritative" CDN Provider, where the CSP requires the CDN Provider to perform the content delivery on the CSP's behalf.
  • A business arrangement between the Authoritative CDN Provider and another CDN (or other CDNs), where the Authoritative CDN may delegate the actual serving of some content delivery requests to those other CDNs. One special case is where this other CDN Provider also happens to be the NSP giving the EU network access. In that case, there's also a separate and independent business relationship between the EU and the NSP for that network access 🍓.

The formation and details of any business relationships between a CSP and a CDN Provider, and between one CDN Provider and another CDN Provider, are out of scope for this document. Still, this document is about the fact that no standards or open specifications currently exist to make such CDN Interconnection happen from a technical perspective 💅.

Here's one possible flow for performing an end-to-end content delivery across a CDN Interconnection:

  • The initial content request from an EU's User Agent is first received by the authoritative (upstream) CDN, which is the CDN that has a business arrangement with the CSP 👑.
  • The authoritative (upstream) CDN may serve the request itself, or it may choose to use CDN Interconnection to redirect the request to a Downstream CDN that's in a better position to do so (for example, a Downstream CDN that's "closer" to the EU) 🧚.
  • The EU's User Agent will "follow" the redirect returned by the Authoritative CDN and request the content from the Downstream CDN. If required, the Downstream CDN will acquire the requested content from the authoritative (upstream) CDN, and if necessary, the Authoritative CDN will acquire the requested content from the Content Service Provider 🔥.

The goal of this document is to outline the problem area of CDN Interconnection. Section 2 talks about the use cases for CDN Interconnection. Section 3 presents the CDNI model and problem area that the IETF is considering. Section 4 describes each CDNI interface individually and highlights example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. Appendix B.2 describes how the CDNI problem space relates to other relevant IETF working groups and IRTF research groups 🌈.

1.1. Terminology ✨

Okay bestie, first things first: this doc has its own glossary, and the terms are used very specifically 💅 Here's how it's defining them:

Authoritative CDN: A CDN that has a direct relationship with a CSP for distributing and delivering that CSP's content, either by itself or through its Downstream CDNs. 🎀

CDN Interconnection (CDNI): A relationship between a pair of CDNs where one CDN can provide content delivery services on behalf of the other. It might be fully or partially set up through a bunch of interfaces that the two CDNs use to talk to each other, so Surrogates in one CDN (the Downstream CDN) can deliver content to User Agents for the other CDN (the Upstream CDN). 🦋

CDN Provider: The service provider that runs a CDN and sells content delivery as a service, usually to a Content Service Provider or to another CDN Provider. Also, one entity can play more than one role. For example, a company can be a Content Service Provider, a Network Service Provider, and a CDN Provider all at once. Multitasking queen 👑

CDNI Metadata: The part of Content Distribution Metadata that has an inter-CDN scope. Examples include geo-blocking info (where content is allowed or blocked, geographically), availability windows (when content is allowed or blocked, time-wise), and access control mechanisms to enforce (like URI signature validation). CDNI Metadata can also cover the desired distribution policy (like pre-positioned vs dynamic acquisition) and where and how a CDN can get the content from. 🗺️

Content: Any form of digital data. One especially important kind is continuous media, which has extra distribution and delivery constraints, because there's a timing relationship between the source and the sink. 🎬

Content Distribution Metadata: The part of Content Metadata that matters for distributing the content. It's the metadata a CDN needs in order to enable and control how the content gets distributed and delivered. In a CDN Interconnection setup, some Content Distribution Metadata has an intra-CDN scope, so it doesn't need to be shared between CDNs, while other Content Distribution Metadata has an inter-CDN scope, so it does need to be shared between CDNs. 🤝

Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure where the network elements work together at Layers 4 through 7 to deliver Content to User Agents more effectively. A CDN usually has a Request Routing system, a Distribution system (which includes a set of Surrogates), a Logging system, and a CDN Control system. 🌐

Content Metadata: Metadata about Content, which breaks down into two types:

  1. Metadata that's relevant to distributing the content (and therefore relevant to any CDN involved in delivering it). We call this "Content Distribution Metadata". See also the definition of Content Distribution Metadata.
  2. Metadata tied to the actual Content or content representation that isn't directly relevant to distribution. For example, this could be stuff like the Content's genre, cast, rating, etc., or the content representation's resolution, aspect ratio, etc. 🍿

Content Service: The service a Content Service Provider offers. The Content Service is the whole package, which can be bigger than just giving access to Content. For example, it also includes any middleware, key distribution, program guide, etc. that might not need any direct interaction with the CDN, or CDNs, doing the distribution and delivery. 🧚

Content Service Provider (CSP): Provides a Content Service to End Users, who access it through a User Agent. A CSP might own the Content it makes available as part of the Content Service, or it might license content rights from someone else. 📺

Control system: The part of a CDN that bootstraps and controls the CDN's other components, and also handles interactions with external systems (like handling requests to create, update, or remove delivery services, or specific service provisioning requests). 🎛️

Delivery: The part of CDN Surrogates that's responsible for delivering a piece of content to the User Agent. For example, delivery might be based on HTTP progressive download or HTTP adaptive streaming. 📦

Distribution system: The part of a CDN that distributes Content Distribution Metadata, as well as the Content itself, inside the CDN (for example, all the way down to the Surrogates). 🚚

Downstream CDN: For a given End User request, this is the CDN (in a pair of directly interconnected CDNs) that the other CDN, the Upstream CDN, redirects the request to. If there are successive redirections (like CDN1-->CDN2-->CDN3), a given CDN (like CDN2) can be the Downstream CDN for one redirection (CDN1-->CDN2) and the Upstream CDN for the next redirection of that same request (CDN2-->CDN3). It's a whole chain of hand-offs, bestie 🔗

Dynamic CDNI Metadata acquisition: In CDN Interconnection, this means a Downstream CDN gets CDNI Metadata for content at some point after the Upstream CDN has delegated a request for that content to it, and only if that specific CDNI Metadata isn't already in the Downstream CDN. See also the definitions for Downstream CDN and Upstream CDN. 🕰️

Dynamic content acquisition: This is when a CDN gets content from the content source because an End User asked for it from the CDN. In CDN Interconnection, dynamic acquisition means a Downstream CDN gets the content from content sources (including Upstream CDNs) at some point after the Upstream CDN delegated the request to it, and only if that specific content isn't already in the Downstream CDN. ⚡

End User (EU): The "real" user of the system. Usually that's a human, but it could also be some mix of hardware and/or software that's pretending to be a human (for example, for automated quality monitoring). 🙋

Logging system: The part of a CDN that collects measurements and records distribution and delivery activities. The info the Logging system records might get used for different stuff, like charging (for example, the CSP), analytics, and monitoring. 📊

Metadata: Metadata in general is data about data. Simple, iconic 🫶

Network Service Provider (NSP): Provides network-based connectivity and services to End Users. 📡

Over-the-top (OTT): A service, like content delivery using a CDN, that's run by a different operator than the NSP the service's users are connected to. 🛸

Pre-positioned CDNI Metadata acquisition: In CDN Interconnection, this is where the Downstream CDN gets CDNI Metadata for content before any End User asks for that content from the Downstream CDN, or independently of any request. 📮

Pre-positioned content acquisition: This is where a CDN gets content from the content source before any End User asks for it from the CDN, or independently of any request. In CDN Interconnection, the Upstream CDN tells the Downstream CDN to get the content from content sources (including Upstream CDNs) ahead of time, or independently of any End User requesting it. 🌅

Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390]. 💯

Request Routing system: The part of a CDN that receives a Content Request from a User Agent, gets and keeps the info it needs about a set of candidate Surrogates or candidate CDNs, and then picks and redirects the user to the right Surrogate or CDN. To enable CDN Interconnection, the Request Routing system also has to be able to handle User Agent Content Requests that another CDN passes to it. 🧭

Surrogate: A device or function (often just called a cache) that works with other parts of the CDN to control and distribute Content inside the CDN, and works with User Agents to deliver the Content. Surrogates usually cache requested content so they can deliver the same content directly to multiple User Agents (and their End Users). That way, the content doesn't have to keep going through the network core (from the content origin to the Surrogate) every single time. 🧁

Upstream CDN: For a given End User request, this is the CDN (in a pair of directly interconnected CDNs) that redirects the request to the other CDN. ⬆️

User Agent (UA): Software (or a mix of hardware and software) that an End User uses to interact with a Content Service. The User Agent talks to a Content Service to pick content, and to one or more CDNs to get the Content delivered. That communication isn't limited to HTTP and can use a variety of protocols. Examples of User Agents (not an exhaustive list) are browsers, Set Top Boxes (STBs), dedicated content apps (like media players), etc. 📱

1.2. CDN Background 🌸

Okay, so this doc assumes you already know your way around CDN architecture, features, and how they run. If you're still getting there, these resources might help:

  • RFC 3040 [RFC3040] describes many of the component technologies that get used to build a CDN. 🧩
  • Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. 🔍
  • RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the IETF Content Distribution Internetworking (CDI) working group, which was closed in 2003. 🗂️
Note: some of the terms in this document are similar to terms used in the referenced documents above. When you read this doc, the terms should be understood with the definitions given in Section 1.1. Don't mix them up, babe! 🫶

2. CDN Interconnection Use Cases ✨

okay so bestie, this section is all about why anyone even needs CDN interconnection 💖 and honestly the reasons are super relatable.

An increasing number of NSPs are deploying CDNs 🌈 to handle the growing demand for on-demand video services and other content delivery apps, and they want to do it in a cost-effective way 💅

So here's the vibe: a CDN lets content get cached closer to the edge of the network 🦋. That means one item of content can be delivered by a CDN Surrogate (aka a cache) to lots of User Agents (and their End Users) without bouncing through the network core over and over again (from the content origin all the way to the Surrogate) 🧚. The payoff? Lower bandwidth costs for the NSP and a better quality of experience for End Users 🌸. CDNs also copy popular content across many Surrogates, so it can reach huge numbers of User Agents at the same time ⭐. That's also a lifesaver for flash crowds and denial-of-service attacks 🛡️ no cap.

The CDNs that NSPs deploy aren't only for their own 'walled garden' stuff, like IP delivery of TV to Set Top Boxes 📺. They also deliver content to PCs, tablets, mobile phones, and other devices 📱💜

Now, some service providers work across multiple geographies and team up with multiple affiliate NSPs 🌍. Those NSPs usually run independent CDNs. As they level up their services (for example, seamless content for nomadic users moving across affiliate NSPs) they need to interconnect those CDNs, and that's our first use case for CDNI 🎀. The tea is, there are no open specifications and no common best practices for how to actually do CDN Interconnection 😭

CSPs want their content to reach very large numbers of End Users, often spread across lots of geographies, while keeping quality high 👑. The catch is they don't want to have direct business deals with a bunch of different CDN Providers, or stretch their own CDN to tons of locations 💀. Some NSPs are thinking about interconnecting their CDNs (and maybe over-the-top CDNs too) so all that infrastructure together can meet CSP needs cost-effectively 🫶. That's our second use case for CDNI ✨. Specifically, CSPs could get on-net delivery (inside the NSP's own network and CDN footprint) whenever possible, and off-net delivery otherwise, without having to make direct deals with every CDN involved 🍓. Again, CDN Providers (NSPs or over-the-top CDN operators) are stuck with no open specs and best practices 😤

NSPs have often built CDNs as specialized cost-cutting projects for one particular service or environment 💅. Some run separate CDNs for separate services. For example, there might be one CDN for managed IPTV delivery, another for web-TV, and another for video delivery to mobile terminals 📺📱. As NSPs bring their service portfolios together, they need to interconnect these CDNs, which is our third use case for CDNI 🌸. NSPs again face the problem of no open interfaces for CDN Interconnection 🙈

Last one! For operational reasons (like a disaster or flash crowd) or commercial reasons, an over-the-top CDN may choose to use another CDN (for example, an NSP CDN with on-net Surrogates for a given footprint) to serve a subset of user requests (like requests from users attached to that NSP) 🦋. That's our fourth use case for CDNI, and once again, CDN Providers (over-the-top or NSP) are dealing with a lack of open specifications and best practices 💜

Use cases for CDN Interconnection are discussed further in [CDNI-USE-CASES] 🧚✨

3. CDN Interconnection Model and Problem Area for IETF ✨

okay so this section is about the problem area for the IETF's CDN Interconnection work 🧚 bestie, interconnecting CDNs involves a whole bunch of different functions and components that make up each CDN, but only some of those need new specs from the IETF 💅

some NSPs have been running experiments to see whether their CDN use cases can already be handled by existing CDN implementations 🔬 one set of those experiments is written up in [CDNI-EXPERIMENTS]. the takeaway is that some basic, limited CDN Interconnection functionality is possible with today's CDN tech, but the lack of any standardized CDNI interfaces with the level of functionality discussed in this document is blocking the deployment of CDN Interconnection 😭

so here are the four interfaces you need to interconnect a pair of CDNs. together they make up the problem space, and for each one we're listing the functionality that has no standards yet 🫶 also, the CDNI interfaces will need common ways to identify and name the data objects that get swapped between the interconnected CDNs. main character requirement ngl 👑

quick note on the word "interface": it covers both the protocol used to exchange CDNI data representations (like CDNI Metadata objects) and the specs for the data representations themselves, meaning what properties and fields each object has, how it's structured, and so on 🎀

  • CDNI Control interface: This interface allows the "CDNI Control" system in interconnected CDNs to communicate. This interface may support the following:
    • Allow bootstrapping of the other CDNI interfaces (e.g., interface address/URL discovery and establishment of security associations).
    • Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface).
    • Allow the Downstream CDN to communicate static (or fairly static) information about its delivery capabilities and policies.
    • Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work).
    • Allow an Upstream CDN to initiate or request specific actions to be undertaken in the Downstream CDN. For example, to allow an Upstream CDN to initiate content or CDNI Metadata acquisition (pre-positioning) or to request the invalidation or purging of content files and/or CDNI Metadata in a Downstream CDN.
  • CDNI Request Routing interface: This interface allows the Request Routing systems in interconnected CDNs to communicate to ensure that an End User request can be (re)directed from an Upstream CDN to a Surrogate in the Downstream CDN, in particular where selection responsibilities may be split across CDNs (for example, the Upstream CDN may be responsible for selecting the Downstream CDN, while the Downstream CDN may be responsible for selecting the actual Surrogate within that Downstream CDN). In particular, the functions of the CDN Request Routing interface may be divided as follows:
    • A CDNI Request Routing Redirection interface, which allows the Upstream CDN to query the Downstream CDN at request routing time before redirecting the request to the Downstream CDN.
    • A CDNI Footprint & Capabilities advertisement interface, which allows the Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents.
  • CDNI Metadata interface: This interface allows the Distribution system in interconnected CDNs to communicate to ensure that CDNI Metadata can be exchanged across CDNs. See Section 1.1 for the definition and examples of CDNI Metadata.
  • CDNI Logging interface: This interface allows the Logging system in interconnected CDNs to communicate the relevant activity logs in order to allow log-consuming applications to operate in a multi-CDN environment. For example, an Upstream CDN may collect delivery logs from a Downstream CDN in order to perform consolidated charging of the CSP or for settlement purposes across CDNs. Similarly, an Upstream CDN may collect delivery logs from a Downstream CDN in order to provide consolidated reporting and monitoring to the CSP.
the grouping of functionality under these four interfaces is still tentative at this stage 🫠 it may change after further study, e.g. some functionality might move from one interface into another

the list above covers a pretty big potential problem space 🌸 that's because interconnecting two CDNs has several "touch points" that need standardizing. the good news is the CDNI interfaces don't need to be built from scratch. they can reuse or lean on existing protocols to a very significant extent (more on this in Section 4) 🦋

here's the CDNI problem area illustrated in Figure 1 🍓

  --------
 /        \
 |   CSP  |
 \        /
  --------
     *
     *
     *                         /\
     *                        /  \
 ----------------------      |CDNI|        ----------------------
/     Upstream CDN     \     |    |       /    Downstream CDN    \
|      +-------------+ | Control Interface| +-------------+      |
|*******   Control   |<======|====|========>|   Control   *******|
|*     +------*----*-+ |     |    |       | +-*----*------+     *|
|*            *    *   |     |    |       |   *    *            *|
|*     +------*------+ | Logging Interface| +------*------+     *|
|* *****   Logging   |<======|====|========>|   Logging   ***** *|
|* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
|* *     *         *   | Request Routing  |   *         *     * *|
.....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
. |* * * +-------------+.|     |    |       | +-------------+ * * *| .
. |* * *                 .  CDNI Metadata   |                 * * *| .
. |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
. |* * * |             | |  .   \  /        | |             | * * *| .
. |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
. |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |*******  +---------+| |   Acquisition    | |+----------+ *******| .
. |      +-------------+ |                  | +-------*-----+      | .
. \                      /                  \         *            / .
.  ----------------------                    ---------*------------  .
.                                                     *              .
.                                                     * Delivery     .
.                                                     *              .
.                                                  +--*---+          .
...............Request.............................| User |..Request..
                                                   | Agent|
                                                   +------+

<==>  interfaces inside the scope of CDNI
****  interfaces outside the scope of CDNI
....  interfaces outside the scope of CDNI

              Figure 1: A Model for the CDNI Problem Area

so, as Figure 1 shows, content acquisition between interconnected CDNs is out of scope for CDNI 🙈 that's a big call, so here's the reasoning. the CDNI problem space is only about defining the control plane, and the CDNI data plane (aka acquiring and distributing the actual content objects) is out of scope. why? CDNs today already usually use standardized protocols like HTTP, FTP, rsync, etc. to pull content from their CSP customers, and the same protocols could be reused for acquisition between interconnected CDNs too 💖 so the problem of content acquisition is basically already solved. the only thing the CDNI working group needs to cover on that front is describing, inside the CDNI Metadata, the parameters needed to retrieve the content, like the IP address/hostname to connect to, which protocol to use to retrieve it, and so on 🎀

4. Scoping the CDNI Problem 🔥

okay so this section shows how the scope of work for the CDNI problem space can be narrowed down by reusing or leveraging existing protocols to build the CDNI interfaces 💅 to be clear, this isn't trying to pick winners for the working group. it's just an illustration that the CDNI interfaces don't have to be built in a vacuum, and that reusing or leveraging existing protocols is probably possible ✨

all four CDNI interfaces from Section 3 (the CDNI Control, Request Routing, Metadata and Logging interfaces) are control plane interfaces working at the application layer (Layer 7 in the OSI network model) 🧚 first off, since these interfaces aren't expected to need any unique session, transport, or network requirements compared to the many other existing apps on the Internet, the CDNI interfaces are expected to be defined on top of existing session, transport, and network protocols 🦋

secondly, a brand-new application protocol could be designed just for CDNI, but our analysis below shows that's unnecessary 🙅‍♀️ it's recommended that existing application protocols get reused or leveraged to realize the CDNI interfaces. for example: HTTP [RFC2616], the Atom Publishing Protocol [RFC5023], and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] 🌈

4.1. CDNI Control Interface 💜

the CDNI Control interface lets the Control system in interconnected CDNs talk to each other 💬 the exact inter-CDN control functionality the CDNI Control interface must support is less well defined than for the other three CDNI interfaces right now 🫤

just like the other CDNI interfaces, it's expected that existing protocols can be reused or leveraged for the Control interface too 🫶

4.2. CDNI Request Routing Interface

Okay bestie, so the CDNI Request Routing interface is how a Request Routing function in an Upstream CDN asks a Request Routing function in a Downstream CDN whether it's able (and willing) to accept the delegated Content Request 💅. It also lets the Downstream CDN decide what gets sent back to the User Agent in the redirection message from the upstream Request Routing function 🎀.

This interface is basically a straightforward request/response thing 🫶, so it could run over any number of request/response protocols ✨. For example, it could be a WebService using one of the common WebServices methods, like Extensible Markup Language-Remote Procedure Calling (XML-RPC) or an HTTP query to a known URI 🌸. Which means the CDNI working group doesn't have to invent a brand new protocol for the request/response part of the CDNI Request Routing interface. Iconic efficiency 👑.

Also, like we talked about in Section 3, the CDNI Request Routing interface is expected to let a Downstream CDN give the Upstream CDN information (static or dynamic) like resources, footprint, and load 🧚. That helps the Upstream CDN's Request Routing system pick the Downstream CDN when it handles later Content Requests from User Agents 💖. The idea is that this could be specified by the CDNI working group while leaning heavily on existing IETF protocols that already distribute reachability information (for example, existing routing protocols) or that support application-level queries for topological information (for example, Application-Layer Traffic Optimization (ALTO) [RFC5693]) 🦋. Main character energy 💜.

4.3. CDNI Metadata Interface

The CDNI Metadata interface lets the Distribution system in a Downstream CDN request CDNI Metadata from an Upstream CDN 📥. That way the Downstream CDN can process and respond properly to redirection requests that come in over the CDNI Request Routing interface, and to Content Requests that arrive directly from User Agents 🌈.

Honestly this one is giving the same vibe as the CDNI Request Routing interface 💅, because it's also a request/response interface ⭐. The difference is that CDNI Metadata search might have more complex semantics than a simple Request Routing redirection request 🙈. So, just like the CDNI Request Routing interface, the CDNI Metadata interface may be implemented as a WebService using one of the common WebServices methods (XML-RPC, an HTTP query to a known URI, etc.), or possibly using other existing protocols such as XMPP [RFC6120] 🍓. Again, this removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface 🎀.

4.4. CDNI Logging Interface

The CDNI Logging interface lets details of content distribution and delivery activities get exchanged between interconnected CDNs 📝. For example, log records about content delivery get shared, kind of like the log records a web server keeps in its access log 🧾.

Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs 🔥. These include the Simple Network Management Protocol (SNMP), syslog, FTP (and secure variants), HTTP POST, etc. 💅

5. Security Considerations

🚨 Okay real talk, this section is SERIOUS. Security is not a vibe to skip, so every single point below matters 😭.

Distribution of content by a CDN comes with a whole range of security considerations 🔐. For example, how do you enforce control of End User access to the content in line with the CSP policy? Or how do you trust the logging information the CDN generates for charging the CSP? 💀 These security aspects are already handled by CDN Providers and CSPs today in the context of standalone CDNs 💖. However, interconnecting CDNs adds a new set of security considerations by extending the trust model to a chain of trust (i.e., the CSP "trusts" a CDN that "trusts" another CDN) 🔗. The mechanisms used to mitigate these risks in multi-CDN environments may be similar to the ones used in the single-CDN case, but their suitability in this more complex environment must be validated 🧐.

Interconnecting CDNs may also bring additional privacy considerations on top of the ones that apply to the single-CDN case 🙈. In a multi-CDN environment, the different CDNs may live in different legal regimes that require different privacy requirements to be enforced 🌍. Those privacy requirements may affect how granular the information exchanged across the CDNI interfaces can be 🎀. For example, the Logging system in a Downstream CDN may need to apply some degree of anonymization, obfuscation, or even the complete removal of some fields before it exchanges log records containing details of End User deliveries with an Upstream CDN 🫣.

Keeping the content itself, its associated metadata (including delivery policies), and the CDNs distributing and delivering it secure is critical for both CDN Providers and CSPs 🛡️. The CDN Interconnection interfaces must provide sufficient mechanisms to keep the overall system of interconnected CDNs secure, as well as the information (content, metadata, logs, etc.) distributed and delivered through any set of interconnected CDNs 👑.

5.1. Security of the CDNI Control Interface

Information exchanged between interconnected CDNs over this interface is very sensitive 🚨. A pair of CDNs uses this interface to bootstrap all the other CDNI interfaces, possibly including setting up the mechanisms for securing those interfaces 🥺. So if this interface gets corrupted, all the other interfaces can get corrupted too 😱. Through this interface, an Upstream CDN may pre-position or delete content or metadata in a Downstream CDN, and a Downstream CDN may provide administrative information to an Upstream CDN, etc. 🍓 All of these operations require that the peer CDNs are appropriately authenticated and that the confidentiality and integrity of information flowing between them can be ensured 🔒.

5.2. Security of the CDNI Request Routing Interface

This interface needs appropriate levels of authentication and confidentiality, because it lets an Upstream CDN query the Downstream CDN in order to redirect requests 🔁. It also works the other way around: the Downstream CDN can influence the Upstream CDN's Request Routing function 🎭.

Without appropriate security on this interface, a rogue Upstream CDN could flood Downstream CDNs with bogus requests, or get the Downstream CDN to send it private information 🚩. And a rogue Downstream CDN could influence the Upstream CDN so the Upstream CDN redirects requests to the rogue Downstream CDN or to another Downstream CDN, for example to attract extra delivery revenue 💸. Villain arc, no cap 💀.

5.3. Security of the CDNI Metadata Interface

This interface lets a Downstream CDN request CDNI Metadata from an Upstream CDN. That means the Upstream CDN must make sure the Downstream CDN is appropriately authenticated before it sends the data 🪪. And the other way around: a Downstream CDN must authenticate an Upstream CDN before requesting metadata, so it stays insulated from poisoning by rogue Upstream CDNs ☣️. The confidentiality and integrity of the information exchanged between the peers must be protected 🫶.

5.4. Security of the CDNI Logging Interface

Logging data can be really sensitive 😭. It can include which End User accessed which media resource, IP addresses of End Users, potential names and subscriber account information, etc. 🙈 Confidentiality of this information must be protected as log records move between CDNs 🔐. The information may also be sensitive because it can be the basis for charging across CDNs 💰. So appropriate levels of protection are needed against corruption, duplication, and loss of this information 🛡️.

6. Acknowledgements

The authors would like to thank Andre Beck, Gilles Bertrand, Mark Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy for their review comments and contributions to the text 🫶💖. Thank you, legends ✨.

7. Informative References 📚

  • [ALTO-CDN-USE-CASES] Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.
  • [ALTO-Charter] "IETF ALTO WG Charter", <http://datatracker.ietf.org/wg/alto/charter/>.
  • [CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012.
  • [CDNI-USE-CASES] Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", Work in Progress, August 2012.
  • [DECADE-Charter] "IETF DECADE WG Charter", <http://datatracker.ietf.org/wg/decade/charter/>.
  • [P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010, <http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>.
  • [PPSP-Charter] "IETF PPSP WG Charter", <http://datatracker.ietf.org/wg/ppsp/charter/>.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
  • [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
  • [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
  • [RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007.
  • [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
  • [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
  • [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
  • [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007, <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.

Appendix A. Design Considerations for Realizing the CDNI Interfaces 🧩

This section expands on how CDNI interfaces can reuse and leverage existing protocols 🔁. Before describing each CDNI interface individually, it highlights example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces 🦋. However, the options discussed here are purely examples and do not present any consensus on protocols to be used later on 🙅‍♀️.

A.1. CDNI Control Interface 🎀

Okay so the CDNI Control interface is where the Control systems in interconnected CDNs get to talk to each other 💬. Ngl, the exact inter-CDN control functionality it's required to support is less well defined than the other three CDNI interfaces right now, so it's giving work in progress 😭.

Still, as we covered in Section 3, the CDNI Control interface may be required to support things like this:

  • Let an Upstream CDN and a Downstream CDN establish, update, or terminate their CDNI interconnection 💅
  • Bootstrap the other CDNI interfaces (e.g., protocol address discovery and establishment of security associations) 🔐
  • Configure the other CDNI interfaces (e.g., the Upstream CDN specifies what gets reported through the CDNI Logging interface) 🧚
  • Let the Downstream CDN share static info about its delivery capabilities, resources, and policies 🍓
  • Bootstrap the interface between CDNs for content acquisition (even if that interface is itself outside the scope of the CDNI work) ✨

It's expected that the Control interface, just like the other CDNI interfaces, can reuse or leverage existing protocols. Those will get a closer look once the Control interface requirements have been refined 🫶.

A.2. CDNI Request Routing Interface 🦋

The CDNI Request Routing interface lets a Request Routing function in an Upstream CDN ask a Request Routing function in a Downstream CDN whether it's able (and willing) to accept the delegated Content Request. It also lets the Downstream CDN control what the upstream Request Routing function returns to the User Agent in the redirection message. Main character energy 👑.

So the CDNI Request Routing interface needs a way for an Upstream CDN to issue a "Redirection Request" to a Downstream CDN. It has to handle cases where the User Agent's initial request to the Upstream CDN arrived over DNS, and cases where it arrived over a content-specific application protocol (e.g., HTTP, the Real Time Streaming Protocol (RTSP), the Real Time Messaging Protocol (RTMP), etc.) 🌸.

A Redirection Request is expected to contain info such as:

  • The protocol (e.g., DNS, HTTP) over which the Upstream CDN received the initial User Agent request.
  • Additional details of the User Agent request that are required for effective Request Routing by the Downstream CDN. For DNS, this would typically be the IP address of the DNS resolver making the request on behalf of the User Agent. For requests received over content-specific application protocols, the Redirection Request could contain a lot more info about the original User Agent request, but at a minimum is expected to include the User Agent's IP address, the equivalent of the HTTP Host header, and the equivalent of the HTTP abs_path as defined in [RFC2616] 🔍.

It should be noted that the CDNI architecture needs to consider that a Downstream CDN may receive requests from User Agents without first receiving a Redirection Request from an Upstream CDN for the corresponding User Agent request. This can happen because, for example:

  • User Agents (or DNS resolvers) may cache DNS or application responses from Request Routers.
  • Responses to Redirection Requests over the Request Routing interface may be cacheable.
  • Some CDNs may rely on simple coarse policies, e.g., CDN B agrees to always serve CDN A's delegated redirection requests, in which case the necessary redirection details are exchanged out of band (of the CDNI interfaces), e.g., configured.
Okay this bit is lowkey important 🙈: the Downstream CDN can get requests that skipped the Redirection Request step entirely, so the architecture has to plan for that.

On receiving a Redirection Request, the Downstream CDN uses the info in it to decide whether it's able (and willing) to accept the delegated Content Request. It then needs to return the result of that decision to the Upstream CDN ✨.

So a Redirection Response from the Downstream CDN is expected to contain info such as:

  • A status code indicating acceptance or rejection (possibly with accompanying reasons).
  • Info that allows redirection by the Upstream CDN. For DNS-based request routing, this is expected to include the equivalent of a DNS record(s) (e.g., a CNAME) that the Upstream CDN should return to the requesting DNS resolver. For application-based request routing, this is expected to include the info needed to construct the application-specific redirection response(s) to return to the requesting User Agent. For HTTP requests from User Agents, this could include a URI that the Upstream CDN could return in an HTTP 3xx response 🦋.

The CDNI Request Routing interface is therefore a pretty straightforward request/response interface, and it could be built on any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.). This means the CDNI working group doesn't need to define a new protocol for the request/response part of the CDNI Request Routing interface 🎉. So the working group would only need to specify:

  • The recommended request/response protocol to use, along with any additional semantics and procedures that are specific to the CDNI Request Routing interface (e.g., handling of malformed requests/responses).
  • The syntax (i.e., representation/encoding) of the redirection requests and responses.
  • The semantics (i.e., meaning and expected contents) of the redirection requests and responses.

Additionally, as discussed in Section 3, the CDNI Request Routing interface is also expected to let a Downstream CDN provide the Upstream CDN with (static or dynamic) info, such as resources, footprint, and load. That helps the Upstream CDN's Request Routing system pick the Downstream CDN when it processes later Content Requests from User Agents. It is expected that this functionality could be specified by the CDNI working group with significant leveraging of existing IETF protocols that distribute reachability information (for example, by leveraging existing routing protocols) or that support application-level queries for topological information (for example, by leveraging ALTO) 🗺️.

A.3. CDNI Metadata Interface 🌈

The CDNI Metadata interface enables the Distribution system in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN, so the Downstream CDN can properly process and respond to:

  • Redirection Requests received over the CDNI Request Routing interface.
  • Content Requests received directly from User Agents.

The CDNI Metadata interface needs to offer a mechanism for an Upstream CDN to:

  • Distribute/update/remove CDNI Metadata to a Downstream CDN.

and/or to allow a Downstream CDN to:

  • Make direct requests for CDNI Metadata objects.
  • Make recursive requests for CDNI Metadata -- for example, to enable a Downstream CDN to walk down a tree of objects with inter-object relationships 🌳.

The CDNI Metadata interface is therefore similar to the CDNI Request Routing interface, since it's a request/response interface. The difference is that CDNI Metadata search may have more complex semantics than a straightforward Request Routing redirection request 🧠. So, like the CDNI Request Routing interface, the CDNI Metadata interface may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.), or possibly using other existing protocols such as XMPP [RFC6120]. This means the CDNI working group doesn't need to define a new protocol for the request/response part of the CDNI Metadata interface 💖.

Thus, the CDNI working group would only need to specify:

  • The recommended request/response protocol to use, along with any additional semantics that are specific to the CDNI Metadata interface (e.g., handling of malformed requests/responses).
  • The syntax (i.e., representation/encoding) of the CDNI Metadata objects that will be exchanged over the interface.
  • The semantics (i.e., meaning and expected contents) of the individual properties of a Metadata object.
  • How the relationships between different CDNI Metadata objects are represented.

A.4. CDNI Logging Interface 💜

The CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs. Think log records about content delivery, kind of like the ones a web server writes to its access log 📝.

Within CDNs today, log records are used for all sorts of things. CDNs use logs to generate Call Data Records (CDRs) for passing to billing and payment systems, and to real-time (and near real-time) analytics systems 📊. Those applications put requirements on the CDNI Logging interface to support guaranteed and timely delivery of log messages between interconnected CDNs. It may also be necessary to be able to prove the integrity of received log messages 🔒.

Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs, including SNMP traps, syslog, FTP, HTTP POST, etc. Still, some of these candidates may not be well suited to meet all the requirements of CDNI. For example, SNMP traps pose scalability concerns. SNMP also doesn't support guaranteed delivery of traps, so log records could get lost. That could mean the CDRs and billing records for that content delivery never get produced, and that the delivery becomes invisible to any analytics platforms 💀.

Although it isn't necessary to define a new protocol for exchanging logs across the CDNI Logging interface, the CDNI working group would still need to specify:

  • The recommended protocol to use.
  • A default set of log fields and of their syntax and semantics. Today there is no standard set of common log fields across different content delivery protocols, and in some cases there isn't even a standard set of log field names and values for different implementations of the same delivery protocol.
  • A default set of conditions that trigger log records to be generated.

Appendix B. Additional Material ✨

Okay so this section just records related info that got produced while the CDNI problem statement was being defined 🌟.

B.1. Non-Goals for IETF 💅

Okay so, here's the stuff the authors want kept OUTSIDE the CDNI working group's lane 🫶 Think of it as the "not my problem bestie" list:

  • The interface between the Content Service Provider and the Authoritative CDN (i.e., the Upstream CDN contracted by the CSP for delivery by this CDN or by its Downstream CDNs).
  • The delivery interface between the delivering CDN Surrogate and the User Agent, such as streaming protocols.
  • The request interface between the User Agent and the Request Routing system of a given CDN. User Agents usually use existing IETF protocols (like HTTP, RTSP, and DNS) to ask a CDN for content, and CDN Request Routing systems use them to redirect those requests, so the CDNI working group doesn't need to invent new protocols here 🌸 Just note that the CDNI control plane interface can indirectly affect some of the info exchanged through this request interface (e.g., URI).
  • The content acquisition interface between CDNs (i.e., the data plane interface for actual delivery of a piece of content from one CDN to the other). This is expected to use existing protocols such as HTTP, or protocols defined in other forums for content acquisition between an origin server and a CDN (e.g., the HTTP-based C2 reference point of the Alliance for Telecommunications Industry Solutions IPTV Interoperability Forum Content on Demand service (ATIS IIF CoD)). So the CDN Interconnection problem space in this document may only care about the agreement/negotiation side: which content acquisition protocol two interconnected CDNs will use, so they can actually work together 🤝
  • End User/User Agent Authentication. Authentication and authorization for End Users and User Agents are the Content Service Provider's job, not CDNI's 🔐
  • Content preparation, including encoding and transcoding. The CDNI architecture is all about distributing content across interconnected CDNs as opaque objects. Interpreting or processing those objects, and optimizing how the Surrogate delivers them to the End User, are out of scope 🎀
  • Digital Rights Management (DRM). DRM is an end-to-end issue between a content protection system and the User Agent 🔒
  • Applications consuming CDNI logs (e.g., charging, analytics, reporting, ...) 📊
  • Internal CDN interfaces and protocols (i.e., interfaces and protocols within one CDN) 🙈
  • Scalability of individual CDNs. Scalability of the CDNI interfaces/approach is in scope, but how an individual CDN scales is not 📈
  • Actual algorithms for selection of CDNs or Surrogates by Request Routing systems. (However, some specific parameters that are required as input to these algorithms may be in scope when they need to be communicated across CDNs ✨)
  • Surrogate algorithms. For example, caching algorithms and content acquisition methods are outside the scope of the CDNI work. Content management (e.g., Content Deletion) is in scope when it relates to CDNI content management policies, but the internal algorithms a cache uses to decide when to stop caching an item of Content (when no specific metadata says otherwise) are out of scope 🧠
  • Element management interfaces.
  • Commercial, business, and legal aspects related to the interconnections of CDNs 💼

B.2. Relationship to Relevant IETF Working Groups and IRTF Research Groups 🌈

B.2.1. ALTO WG 🗺️

The ALTO working group charter [ALTO-Charter] basically says that the group is designing an Application-Layer Traffic Optimization (ALTO) service. Its job is to give applications info so they can do better-than-random initial peer selection. ALTO services can balance things like maximum bandwidth, minimum cross-domain traffic, and lowest cost to the user in different ways. The group is also looking at the needs of BitTorrent, tracker-less P2P, and other apps, including content delivery networks (CDN) and mirror selection.

So yes, the ALTO service can be used by a CDN Request Routing system to pick a better CDN Surrogate for a particular User Agent request (or for a request coming from another Surrogate) 🙌 [ALTO-CDN-USE-CASES] lists a bunch of use cases where a CDN gets network topology and cost info from ALTO server(s), and it talks about how CDN Request Routing could be the spot where ALTO plugs into CDNs. The same idea could work in a multi-CDN environment built on CDN Interconnection. For example, an Upstream CDN could use the ALTO service when deciding which Downstream CDN to delegate a user request to 💅

BUT, the current ALTO work is complementary to this document and doesn't overlap with it. How ALTO gets integrated with a CDN is an internal decision for each specific CDN, so it's out of scope for the CDNI working group 🙈 One thing that's still up for further study is whether an ALTO service should provide extra info to help with CDNI CDN selection.

B.2.2. DECADE WG 🏠

The DECADE working group [DECADE-Charter] is working on cutting down traffic on the last-mile uplink, plus backbone and transit links, caused by peer-to-peer (P2P) streaming and file-sharing apps. The way it does that is by letting an application endpoint make content available from an in-network storage service, and then letting other application endpoints grab the content from there 📦

Storing and exchanging data through that in-network storage service, instead of talking directly peer to peer, gives a big win when:

  • The network capacity/bandwidth from the in-network storage service to the application endpoint is much higher than the capacity/bandwidth from application endpoint to application endpoint (e.g., because of an end-user uplink bottleneck); and
  • The content is going to be accessed by multiple instances of application endpoints (e.g., as is typically the case for P2P applications) 📈

So DECADE's architecture and mechanisms could in theory be used to swap CDNI control plane info through an in-network storage service (instead of directly between the entities terminating the CDNI interfaces in neighbor CDNs). But there are a few things to know:

  • CDNI would operate as a "Content Distribution Application" from the DECADE viewpoint (i.e., it would run on top of DECADE) 🍰
  • There don't seem to be obvious benefits in integrating the DECADE control plane (which handles signaling for controlling the in-network storage service itself) with the CDNI control plane (which handles the application-specific CDNI stuff, like exchanging CDNI Metadata, CDNI request redirection, and transferring CDNI logging information) 🤷‍♀️
  • Using a DECADE in-network storage service would usually bring limited benefits, because the CDNI interfaces are expected to be terminated by a very small number of CDNI clients (if not just one) in each CDN. Those CDNI clients should get high bandwidth/capacity when talking directly to each other, at least as high as they'd get going through an in-network storage server 🚀

The DECADE in-network storage architecture and mechanisms might theoretically also be used to acquire the content objects themselves between interconnected CDNs. It isn't expected to offer obvious benefits in typical situations, where a content object is acquired only once from an Upstream CDN to a Downstream CDN and then distributed as needed inside the Downstream CDN. It might help in some particular situations, though. Since the acquisition protocol between CDNs is outside the scope of CDNI work, this question is left for further study 👀

DECADE's in-network storage could potentially also be used inside a given CDN to distribute the content objects among that CDN's Surrogates. Since CDNI work doesn't cover operation within a CDN, this one's also left for further study 🔍

So, the work of DECADE may be complementary to the CDNI work described in this document, but it doesn't overlap with it ✨

B.2.3. PPSP WG 📺

The PPSP working group charter [PPSP-Charter] describes the Peer-to-Peer Streaming Protocol (PPSP) working group as developing two signaling and control protocols for a peer-to-peer (P2P) streaming system. That system transmits live and time-shifted media content with near real-time delivery requirements. The group is designing a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol"), and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). Together, the two protocols let peers receive streaming data within the time constraints that each specific content item requires.

So PPSP is all about distributing the streamed content itself, along with the signaling and control needed to distribute it 🎬 That means it could potentially be used to acquire streamed content across interconnected CDNs. But since the acquisition protocol is outside the scope of the CDNI work, that's left for further study. Also, because of its streaming nature, PPSP isn't seen as applicable to distributing and controlling the CDNI control plane and CDNI data representations 🙅‍♀️

So, the work of PPSP may be complementary to the work described in this document for CDNI, but it doesn't overlap with it 💖

B.2.4. IRTF P2P Research Group 🧪

Some info on CDN Interconnection motivations and technical issues was presented in the P2P research group at IETF 77. You can find that presentation in [P2PRG-CDNI] 🎀

Authors' Addresses 🖋️

Ben Niven-Jenkins Velocix (Alcatel-Lucent) 326 Cambridge Science Park Milton Road, Cambridge CB4 0WG UK

EMail: ben@velocix.com

Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France

Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com

Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02145 USA

EMail: nabil.n.bitar@verizon.com

📦 where this page comes from