< draft-bertrand-cdni-experiments-00.txt   draft-bertrand-cdni-experiments-01.txt >
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft France Telecom R&D Internet-Draft France Telecom - Orange
Intended status: Informational F. Le Faucheur Intended status: Informational F. Le Faucheur
Expires: August 20, 2011 Cisco Systems Expires: February 20, 2012 Cisco Systems
L. Peterson L. Peterson
Verivue, Inc. Verivue, Inc.
February 16, 2011 August 19, 2011
Content Distribution Network Interconnection (CDNI) Experiments Content Distribution Network Interconnection (CDNI) Experiments
draft-bertrand-cdni-experiments-00 draft-bertrand-cdni-experiments-01
Abstract Abstract
This document reports studies and related experiments on CDN This document reports studies and related experiments on CDN
interconnection performed by France Telecom-Orange Labs. The interconnection performed by France Telecom-Orange Labs. The
document summarizes implications of CDN interconnection to CDN document summarizes implications of CDN interconnection to CDN
service providers and lessons learned through CDNI experiments. service providers and lessons learned through CDNI experiments.
The main purpose of the experiments was to test the interconnection The main purpose of the experiments was to test the interconnection
of CDN solutions from two vendors (namely, Cisco and Verivue) and to of CDN solutions from two vendors (namely, Cisco and Verivue) and to
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2011. This Internet-Draft will expire on February 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDN Interconnection Experiments . . . . . . . . . . . . . . . 6 2. CDN Interconnection Experiments . . . . . . . . . . . . . . . 5
2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 6 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 5
2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Request Routing and Content Delivery . . . . . . . . . . . 7 2.4. Request Routing and Content Delivery . . . . . . . . . . . 7
2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 8 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 8
2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 10 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 10
2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 13 2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 12
2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 13 2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 13
2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 13 2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 13
2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 13 2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 13
2.6.2. Content Acquisition by CDN A Directly from CSP B . . . 15 2.6.2. Content Acquisition by CDN A Directly from CP B . . . 14
3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 15 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 16 3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Request-Routing Information and Policies . . . . . . . 16 3.1.1. Request-Routing Information and Policies . . . . . . . 16
3.1.2. Iterative and Recursive Redirection . . . . . . . . . 16 3.1.2. Iterative and Recursive Redirection . . . . . . . . . 16
3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 17 3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 17
3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 17 3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 17
3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 18 3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 18
3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 18 3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 18
3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 18 3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 18
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document reports studies and related experiments on CDN This document reports studies and related experiments on CDN
skipping to change at page 4, line 27 skipping to change at page 4, line 27
This study is not intended to explore the entire scope of CDNI, and This study is not intended to explore the entire scope of CDNI, and
in fact, it purposely takes a minimalist approach. That is, we focus in fact, it purposely takes a minimalist approach. That is, we focus
on what's minimally required to interconnect two cooperating CDNs in on what's minimally required to interconnect two cooperating CDNs in
a "best effort" way. This provides a constructive foundation for a "best effort" way. This provides a constructive foundation for
adding requirements and mechanisms only after they prove essential in adding requirements and mechanisms only after they prove essential in
practice. practice.
1.1. Terminology 1.1. Terminology
Except for the terms defined below, we adopt the terminology Except for the terms defined below, we adopt the terminology
described in [RFC3466], [RFC3568], and [RFC3570]. described in [RFC3466], [RFC3568], [RFC3570], the problem statement
draft [I-D.jenkins-cdni-problem-statement] and the use cases draft
The problem statement draft [I-D.jenkins-cdni-problem-statement] and [I-D.bertrand-cdni-use-cases].
the use cases draft [I-D.bertrand-cdni-use-cases] define a set of
terms. Below we recall only the terms used in the memo.
Content Service Provider (CSP):
Provides Content Services to Users. A CSP may own the content made
available as part of the Content Service, or may license content
rights from another party.
Content Service:
The service offered by a CSP. The Content Service encompasses the
complete service which may be wider than just the delivery of items
of Content, e.g., the Content Service also includes any middle-ware,
key distribution, program guide, etc., which may not require any
direct interaction with the CDN.
Content Distribution Network (CDN) / Content Delivery Network (CDN): Content Distribution Network (CDN) / Content Delivery Network (CDN):
A type of network in which the components are arranged for more A type of network in which the components are arranged for more
effective delivery of content to User Agents. effective delivery of content to User Agents.
Content Delivery Service Content Delivery Service
Set of services offered to CSPs for delivering their contents through
a single Content Delivery Network or interconnections of Content Set of services offered to content providers (CPs) for delivering
Delivery Networks. their content through a single Content Delivery Network or
interconnections of Content Delivery Networks.
CDN Service Provider (CDSP): CDN Service Provider (CDSP):
An administrative entity who operates a CDN over a Network Service An administrative entity who operates a CDN over a Network Service
Provider (NSP) or over the Internet. Provider (NSP) or over the Internet.
Authoritative CDN (aCDN): Authoritative CDN (aCDN):
The CDSP contracted by the CSP for delivery of content by this CDN or The CDSP contracted by the CP for delivery of content by this CDN or
by its downstream CDNs. by its downstream CDNs.
Downstream CDN (dCDN): Downstream CDN (dCDN):
A CDSP which is contracted by an aCDN to achieve the delivery of A CDSP which is contracted by an upstream CDN to achieve the delivery
content to users. of content to users.
CDN Interconnection (CDNI): CDN Interconnection (CDNI):
Relationship between two CDNs that enables a CDN to provide content Relationship between two CDNs that enables a CDN to provide content
delivery services on behalf of another CDN. It relies on a set of delivery services on behalf of another CDN. It relies on a set of
interfaces over which two CDNs communicate in order to achieve the interfaces over which two CDNs communicate in order to achieve the
delivery of content to end-users by one CDN (the downstream CDN) on delivery of content to end-users by one CDN (the downstream CDN) on
behalf of another CDN (the upstream CDN). behalf of another CDN (the upstream CDN).
Recursive Request Routing: Recursive Request Routing:
skipping to change at page 6, line 21 skipping to change at page 6, line 6
been tested. These tests have been run with CDN solutions from Cisco been tested. These tests have been run with CDN solutions from Cisco
(hereafter referred to as Vendor A) and from Verivue/CoBlitz (hereafter referred to as Vendor A) and from Verivue/CoBlitz
(hereafter referred to as Vendor B). (hereafter referred to as Vendor B).
As depicted in Figure 1, we have interconnected two experimental CDNs As depicted in Figure 1, we have interconnected two experimental CDNs
(CDN A and CDN B) operated by different subsidiaries of a large CDSP. (CDN A and CDN B) operated by different subsidiaries of a large CDSP.
The CDNs lab equipment were located in two different countries, The CDNs lab equipment were located in two different countries,
henceforth referred to as Country A and Country B and they relied on henceforth referred to as Country A and Country B and they relied on
CDN solutions from two different equipment vendors, namely, Vendor A CDN solutions from two different equipment vendors, namely, Vendor A
and Vendor B. The CDNI experiment supported the services of two and Vendor B. The CDNI experiment supported the services of two
emulated CSPs (CSP A and CSP B). emulated CPs (CP A and CP B).
+-------+ : +-------+ +-------+ : +-------+
| CSP A | : | CSP B | | CP A | : | CP B |
+-------+ : +-------+ +-------+ : +-------+
| : | | : |
,--,--,--. : ,--,--,--. ,--,--,--. : ,--,--,--.
,-' CDN A `-. : ,-' CDN B `-. ,-' CDN A `-. : ,-' CDN B `-.
( (Vendor A) )=====( (Vendor B) ) ( (Vendor A) )=====( (Vendor B) )
`-. ,-' : `-. ,-' `-. ,-' : `-. ,-'
`--'--'--' : `--'--'--' `--'--'--' : `--'--'--'
: :
COUNTRY A : COUNTRY B COUNTRY A : COUNTRY B
=== CDN Interconnect === CDN Interconnect
Figure 1 Figure 1
More precisely, we have run the experiments represented in Figure 2 More precisely, we have run the experiments represented in Figure 2
and Figure 4. We base our description on Figure 2. In this and Figure 4. We base our description on Figure 2. In this
experiment, CSP A has an agreement with CDSP A for content delivery experiment, CP A has an agreement with CDSP A for content delivery to
to end-users located in Country A and Country B. However, CDSP A end-users located in Country A and Country B. However, CDSP A
operates a CDN (CDN A), whose footprint does not include country B. operates a CDN (CDN A), whose footprint does not include country B.
Therefore, CDSP A has an agreement with CDSP B, so that CDN A can Therefore, CDSP A has an agreement with CDSP B, so that CDN A can
delegate to CDN B the delivery of some content. More specifically, delegate to CDN B the delivery of some content. More specifically,
CDN A is allowed to delegate to CDN B the handling of requests sent CDN A is allowed to delegate to CDN B the handling of requests sent
by end-users located in Country B for CSP A's content. by end-users located in Country B for CP A's content.
When CDN A receives a content request related to CSP A and from an When CDN A receives a content request related to CP A and from an
end-user in Country B, it redirects the end-user to CDN B. If CDN B end-user in Country B, it redirects the end-user to CDN B. If CDN B
does not have a local copy of the requested content yet (cache miss), does not have a local copy of the requested content yet (cache miss),
CDN B ingests the content from CDN A (or from the CSP origin servers, CDN B ingests the content from CDN A (or from the CP's origin
depending on the test scenario); if CDN A also does not have a local servers, depending on the test scenario); if CDN A also does not have
copy of the requested content, it requests this asset from the CSP a local copy of the requested content, it requests this asset from
origin servers before sending the asset to CDN B. the CP's origin servers before sending the asset to CDN B.
There are several differences between the tests in Figure 2 and There are several differences between the tests in Figure 2 and
Figure 4, in addition to the different role played by the two CDN Figure 4, in addition to the different role played by the two CDN
solutions. We list the main ones below. solutions. We list the main ones below.
o We have tested different content acquisition methods (see o We have tested different content acquisition methods (see
Section 2.6). Section 2.6).
o Specific URL schemes were involved in providing content o Specific URL schemes were involved in providing content
acquisition source information to the downstream CDN. As we have acquisition source information to the downstream CDN. As we have
skipping to change at page 8, line 37 skipping to change at page 8, line 21
redirection by CDN A and delivery by CDN B. redirection by CDN A and delivery by CDN B.
We have tested the selection of the downstream CDN based on the We have tested the selection of the downstream CDN based on the
content type in the client request and/or the geographic location of content type in the client request and/or the geographic location of
the client. the client.
o File-type based selection relied on static XML files where content o File-type based selection relied on static XML files where content
file extensions can be associated to a specific delivery CDN. file extensions can be associated to a specific delivery CDN.
o The geographic location of the end-user was determined by an o The geographic location of the end-user was determined by an
external Geolocation server. external geolocation server.
+-------+ : +-------+ :
| CSP A | : | CP A | :
+-------+ : +-------+ :
| : | :
,--,--,--. : ,--,--,--. ,--,--,--. : ,--,--,--.
,-' CDN A `-. : ,-' CDN B `-. ,-' CDN A `-. : ,-' CDN B `-.
( (Vendor A) )=====( (Vendor B) ) ( (Vendor A) )=====( (Vendor B) )
`-. CDSP A ,-' : `-. CDSP B ,-' `-. CDSP A ,-' : `-. CDSP B ,-'
`--'--'--' : `--'--'--' `--'--'--' : `--'--'--'
: | : |
: +------+ : +------+
: | EU B | : | EU B |
skipping to change at page 9, line 28 skipping to change at page 9, line 5
: :
COUNTRY A : COUNTRY B COUNTRY A : COUNTRY B
=== CDN Interconnect === CDN Interconnect
Figure 2 Figure 2
Figure 3 details the messages exchanged by the components involved in Figure 3 details the messages exchanged by the components involved in
the experiment. the experiment.
End-User CSP A End-User CP A
served by contract with served by contract with
CDN B DNS CDN A Geoloc CDN B SurgtB CDN A CDN B DNS CDN A Geoloc CDN B SurgtB CDN A
| DNS REQ (1)| | | | | | | DNS REQ (1)| | | | | |
|----------->| | | | | | |----------->| | | | | |
| DNS REP (2)| | | | | | | DNS REP (2)| | | | | |
|<-----------| | | | | | |<-----------| | | | | |
| HTTP GET (3) | | | | | | HTTP GET (3) | | | | |
|------------+------->| (3.1) | | | | |------------+------->| (3.1) | | | |
| | |------->| | | | | | |------->| | | |
| | | (3.2) | | | | | | | (3.2) | | | |
skipping to change at page 11, line 12 skipping to change at page 11, line 6
We have tested the selection of the downstream CDN based on end- We have tested the selection of the downstream CDN based on end-
user's geolocation. For these tests, the geolocation database had user's geolocation. For these tests, the geolocation database had
been populated manually with the mapping of IP prefixes to countries. been populated manually with the mapping of IP prefixes to countries.
Alternative solutions, such as geolocation based on BGP communities Alternative solutions, such as geolocation based on BGP communities
or on the extraction of per country IP prefixes thanks to commercial or on the extraction of per country IP prefixes thanks to commercial
geoIP databases, exist but they have not been tested in this geoIP databases, exist but they have not been tested in this
experiment. experiment.
: +-------+ : +-------+
: | CSP B | : | CP B |
: +-------+ : +-------+
: | : |
,--,--,--. : ,--,--,--. ,--,--,--. : ,--,--,--.
,-' CDN A `-. : ,-' CDN B `-. ,-' CDN A `-. : ,-' CDN B `-.
( (Vendor A) )=====( (Vendor B) ) ( (Vendor A) )=====( (Vendor B) )
`-. CDSP A ,-' : `-. CDSP B ,-' `-. CDSP A ,-' : `-. CDSP B ,-'
`--'--'--' : `--'--'--' `--'--'--' : `--'--'--'
| : | :
+------+ : +------+ :
| EU A | : | EU A | :
skipping to change at page 12, line 5 skipping to change at page 11, line 28
: :
COUNTRY A : COUNTRY B COUNTRY A : COUNTRY B
=== CDN Interconnect === CDN Interconnect
Figure 4 Figure 4
Figure 5 details the messages exchanged by the components involved in Figure 5 details the messages exchanged by the components involved in
the experiment. the experiment.
End-User CSP B End-User CP B
served by contract with served by contract with
CDN A DNS CDN A Srgt A CDN B CDN B CDN A DNS CDN A Srgt A CDN B CDN B
| DNS REQ (1)| | | | | | DNS REQ (1)| | | | |
|----------->| | | | | |----------->| | | | |
| DNS REP (2)| | | | | | DNS REP (2)| | | | |
|<-----------| | | | | |<-----------| | | | |
| HTTP GET (3) | | | | | HTTP GET (3) | | | |
|------------+--------+-------+------->| | |------------+--------+-------+------->| |
| HTTP 302 (4) | | | | | HTTP 302 (4) | | | |
|<-----------+--------+-------+--------| | |<-----------+--------+-------+--------| |
skipping to change at page 13, line 20 skipping to change at page 12, line 44
(8) The surrogate analyzes the request and delivers the requested (8) The surrogate analyzes the request and delivers the requested
content to the end-user, through an HTTP 200 OK message. content to the end-user, through an HTTP 200 OK message.
2.4.3. Test Result 2.4.3. Test Result
HTTP redirection by the authoritative CDN was successful in the HTTP redirection by the authoritative CDN was successful in the
tests: end-users were redirected to the CDN that served their tests: end-users were redirected to the CDN that served their
country. This guaranteed that: country. This guaranteed that:
o content from CSP A be delivered by CDN B to end-users in country o content from CP A be delivered by CDN B to end-users in country B,
B, even if CSP A had no direct relationship with CDSP B; even if CP A had no direct relationship with CDSP B;
o content from CSP B be delivered by CDN A to end-users in country o content from CP B be delivered by CDN A to end-users in country A,
A, even if CSP B had no direct relationship with CDSP A. even if CP B had no direct relationship with CDSP A.
2.5. Content Delivery Metadata 2.5. Content Delivery Metadata
The tested CDN solutions feature proprietary Metadata APIs, but these The tested CDN solutions feature proprietary metadata APIs, but these
APIs have not been covered by the tests. We had to configure APIs have not been covered by the tests. We had to configure
distribution metadata consistently in the dCDN and the uCDN (e.g., distribution metadata consistently in the dCDN and the uCDN (e.g.,
rules to determine upstream source for content acquisition). rules to determine upstream source for content acquisition).
Content pre-positioning in the dCDN has not been tested: only dynamic Content pre-positioning in the dCDN has not been tested: only dynamic
content acquisition has been covered by the experiments. content acquisition has been covered by the experiments.
Proprietary APIs were available for content purge, but those have not Proprietary APIs were available for content purge, but those have not
been covered by tests. been covered by tests.
2.6. Content Acquisition 2.6. Content Acquisition
We have used regular HTTP for Content Acquisition. We have relied on We have used regular HTTP for content acquisition. We have relied on
HTTP custom headers to transfer trivial metadata such as content HTTP custom headers to transfer trivial metadata such as content
integrity check (MD5 hash). integrity check (MD5 hash).
The correct acquisition and delivery of the requested file has been The correct acquisition and delivery of the requested file has been
tested for Adobe Flash and MS HTTP smooth-streaming files. tested for Adobe Flash and MS HTTP smooth-streaming files.
2.6.1. Content Acquisition by CDN B through CDN A 2.6.1. Content Acquisition by CDN B through CDN A
We describe here the content acquisition operations triggered in case We describe here the content acquisition operations triggered in case
of cache miss, for the test scenario depicted in Figure 2 and of cache miss, for the test scenario depicted in Figure 2 and
Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In
this scenario, the dCDN (CDN B) does not have the requested content this scenario, the dCDN (CDN B) does not have the requested content
in cache and must request it to the uCDN (CDN A). in cache and must request it to the uCDN (CDN A).
The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides
a summary (the involved internal entities of the uCDN are not a summary (the involved internal entities of the uCDN are not
detailed) of the related content acquisition operations. detailed) of the related content acquisition operations.
Section 3.1.3 provides more details on specific issues related to Section 3.1.3 provides more details on specific issues related to
this content acquisition mode. this content acquisition mode.
End-User CSP A End-User CP A
served by contract with served by contract with
CDN B DNS CDN A Geoloc CDN B CDN A CDN B DNS CDN A Geoloc CDN B CDN A
| | | | | | | | | | | |
| | | HTTP GET (7.1) | | | | | HTTP GET (7.1) | |
| | |<--------+-----------| | | | |<--------+-----------| |
| | | HTTP GET (7.2) | | | | | HTTP GET (7.2) | |
| | |---------+-----------+----------->| | | |---------+-----------+----------->|
| | | HTTP 200 OK (7.3) | | | | | HTTP 200 OK (7.3) | |
| | |<--------+-----------+------------| | | |<--------+-----------+------------|
| | | HTTP 200 OK (7.4) | | | | | HTTP 200 OK (7.4) | |
skipping to change at page 14, line 42 skipping to change at page 14, line 33
Message details Message details
(7.1) CDN B surrogate or parent cache sends a content acquisition (7.1) CDN B surrogate or parent cache sends a content acquisition
request to the uCDN (CDN A). In the tests, (7.1) was triggered by a request to the uCDN (CDN A). In the tests, (7.1) was triggered by a
cache miss on delivery request. Stated differently, the tests cache miss on delivery request. Stated differently, the tests
implemented dynamic acquisition, as opposed to content pre- implemented dynamic acquisition, as opposed to content pre-
positioning. positioning.
(7.2) CDN A analyzes the request. In case of cache miss, it sends an (7.2) CDN A analyzes the request. In case of cache miss, it sends an
acquisition request to the CSP's origin servers. acquisition request to the CP's origin servers.
(7.3) The CSP's origin server authorizes the request and delivers the (7.3) The CP's origin server authorizes the request and delivers the
requested content to CDN A, through an HTTP 200 OK. requested content to CDN A, through an HTTP 200 OK.
(7.4) CDN A delivers the requested content to CDN B surrogate or (7.4) CDN A delivers the requested content to CDN B surrogate or
parent cache, through an HTTP 200 OK. parent cache, through an HTTP 200 OK.
2.6.2. Content Acquisition by CDN A Directly from CSP B 2.6.2. Content Acquisition by CDN A Directly from CP B
We describe here (Figure 7) the content acquisition operations We describe here (Figure 7) the content acquisition operations
triggered in case of cache miss, for the test scenario with HTTP triggered in case of cache miss, for the test scenario with HTTP
redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5). redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5).
In this scenario, the dCDN (CDN A) does not have the requested In this scenario, the dCDN (CDN A) does not have the requested
content in cache and must request it to CSP B. content in cache and must request it to CP B.
End-User CSP B End-User CP B
served by contract with served by contract with
CDN A DNS CDN A CDN B CDN B CDN A DNS CDN A CDN B CDN B
| | | | | | | | | |
| | |HTTP GET (7.1) | | | |HTTP GET (7.1) |
| | |-------------+----------->| | | |-------------+----------->|
| | |HTTP 200 OK (7.2) | | | |HTTP 200 OK (7.2) |
| | |<------------+------------| | | |<------------+------------|
Pull content acquisition by CDN A directly from content provider's Pull content acquisition by CDN A directly from content provider's
origin servers in case of cache miss (continuation of Figure 5) origin servers in case of cache miss (continuation of Figure 5)
Figure 7 Figure 7
Message details Message details
(7.1) CDN A surrogate sends a content acquisition request to an (7.1) CDN A surrogate sends a content acquisition request to an
origin server of the CSP. In the tests, (7.1) was triggered by a origin server of the CP. In the tests, (7.1) was triggered by a
cache miss on a delivery request. Stated differently, the tests cache miss on a delivery request. Stated differently, the tests
implemented dynamic acquisition, as opposed to content pre- implemented dynamic acquisition, as opposed to content pre-
positioning. positioning.
(7.2) The CSP's origin server authorizes the request and delivers the (7.2) The CP's origin server authorizes the request and delivers the
requested content to CDN A, through an HTTP 200 OK. requested content to CDN A, through an HTTP 200 OK.
3. Lessons Learned 3. Lessons Learned
For basic interconnection tests, we have relied on extremely limited For basic interconnection tests, we have relied on extremely limited
information exchanges between the two interconnected CDNs and we have information exchanges between the two interconnected CDNs and we have
configured most CDNI related features manually. This is because, configured most CDNI related features manually. This is because,
while present CDN technologies support APIs allowing configuration of while present CDN technologies support APIs allowing configuration of
some of this information, those are difficult to use in multi-vendor some of this information, those are difficult to use in multi-vendor
environments since: environments since:
skipping to change at page 17, line 4 skipping to change at page 16, line 41
Because of the lack of CDNI interfaces allowing an upstream CDN to Because of the lack of CDNI interfaces allowing an upstream CDN to
query dCDN for how to redirect a request, the tests only covered query dCDN for how to redirect a request, the tests only covered
iterative redirection (i.e. uCDN redirects the user-agent to the dCDN iterative redirection (i.e. uCDN redirects the user-agent to the dCDN
request-routing system, which redirects the user-agent to ...), not request-routing system, which redirects the user-agent to ...), not
recursive redirection. recursive redirection.
While iterative redirection allows supporting redirection across While iterative redirection allows supporting redirection across
CDNs, it has some limitations: CDNs, it has some limitations:
o multiple redirections are exposed to the end-user; o multiple redirections are exposed to the end-user;
o redirection latency cannot easily be reduced for future requests, o redirection latency cannot easily be reduced for future requests,
through the caching of request-routing decisions; through the caching of request-routing decisions;
o some client implementations support a limited number of successive o some client implementations support a limited number of successive
redirections; redirections;
o the dCDN cannot reject a redirection, while allowing the uCDN to o the dCDN cannot reject a redirection, while allowing the uCDN to
handle the rejected request. handle the rejected request.
A standard request-routing API would allow supporting recursive A standard request-routing API would allow supporting recursive
redirection, which removes these shortcomings. redirection, which removes these shortcomings.
3.1.3. Request Looping Avoidance 3.1.3. Request Looping Avoidance
In case of cache-miss, the downstream CDN must fetch the requested In case of cache-miss, the downstream CDN must fetch the requested
content, either through the authoritative CDN, or directly from the content, either through the authoritative CDN, or directly from the
CSP's origin server. CP's origin server.
Consider the situation where the downstream CDN fetches the content Consider the situation where the downstream CDN fetches the content
from the authoritative CDN, as illustrated in Section 2.6.1. In this from the authoritative CDN, as illustrated in Section 2.6.1. In this
case, the authoritative CDN must not redirect the acquisition request case, the authoritative CDN must not redirect the acquisition request
to the downstream CDN, because this would create the following to the downstream CDN, because this would create the following
request-routing loop: dCDN -> uCDN -> dCDN. Consequently, the request-routing loop: dCDN -> uCDN -> dCDN. Consequently, the
upstream CDN must be able to determine that the source of the request upstream CDN must be able to determine that the source of the request
is a partner CDN and not a regular end-user. In addition, the is a partner CDN and not a regular end-user. In addition, the
upstream CDN must be able to, to acquire content from the CSP's upstream CDN must be able to acquire content from the CP's origin
origin server on behalf of the downstream CDN, if necessary: dCDN -> server on behalf of the downstream CDN, if necessary: dCDN -> uCDN ->
uCDN -> CSP. CP.
In the tests, we have successfully solved the request-looping issue, In the tests, we have successfully solved the request-looping issue,
through the use of separated URL spaces for regular users and CDN through the use of separated URL spaces for regular users and CDN
users, as well as the manual configuration of appropriate request- users, as well as the manual configuration of appropriate request-
routing policies for every URL space. In other words, the URL used routing policies for every URL space. In other words, the URL used
by regular users to fetch content was different from the one used by by regular users to fetch content was different from the one used by
the downstream CDN to fetch the content. This way, we eliminated the the downstream CDN to fetch the content. This way, we eliminated the
loops. More automated operation would be required in larger-scale loops. More automated operation would be required in larger-scale
deployments. deployments.
skipping to change at page 18, line 11 skipping to change at page 17, line 49
indirectly via conveying a handle inside the URI and configuring indirectly via conveying a handle inside the URI and configuring
manually in the downstream CDN rules for extracting the upstream manually in the downstream CDN rules for extracting the upstream
source. source.
The upstream source for content acquisition can be specified through The upstream source for content acquisition can be specified through
the use of a specific URI scheme. For example, CDN A could use the the use of a specific URI scheme. For example, CDN A could use the
following scheme: http://cdni.cdna.com/origin-URI to point to a following scheme: http://cdni.cdna.com/origin-URI to point to a
cached copy of the content reachable at "origin-URI". The domain cached copy of the content reachable at "origin-URI". The domain
name inside the URI scheme designates the request-routing system of a name inside the URI scheme designates the request-routing system of a
CDN, and the remainder of the URI defines upstream source for content CDN, and the remainder of the URI defines upstream source for content
acquisition: here, the content URI on the CSP's origin servers. If acquisition: here, the content URI on the CP's origin servers. If
the authoritative CDN and the downstream CDN use this URI scheme, the the authoritative CDN and the downstream CDN use this URI scheme, the
authoritative CDN can easily map the URI that it receives in the end- authoritative CDN can easily map the URI that it receives in the end-
user's content request with a valid URI on the downstream CDN. user's content request with a valid URI on the downstream CDN.
Similarly, the downstream CDN can easily extract a content Similarly, the downstream CDN can easily extract a content
acquisition URI from the redirection URI. acquisition URI from the redirection URI.
In our tests, we have configured manually the rules that enabled the In our tests, we have configured manually the rules that enabled the
authoritative CDN to redirect end-users to a valid URI on the authoritative CDN to redirect end-users to a valid URI on the
downstream CDN, and the downstream CDN to ingest content from the downstream CDN, and the downstream CDN to ingest content from the
appropriate upstream source. While this allowed validation of the appropriate upstream source. While this allowed validation of the
skipping to change at page 18, line 40 skipping to change at page 18, line 30
3.3. Content Acquisition and Deletion 3.3. Content Acquisition and Deletion
3.3.1. Content Pre-Positioning in Downstream CDN 3.3.1. Content Pre-Positioning in Downstream CDN
CDN technology typically supports APIs that allow triggering of CDN technology typically supports APIs that allow triggering of
content and metadata pre-positioning in a CDN. However, while often content and metadata pre-positioning in a CDN. However, while often
similar, these APIs are proprietary and would require custom support. similar, these APIs are proprietary and would require custom support.
For this reason content pre-positioning in dCDN was not covered in For this reason content pre-positioning in dCDN was not covered in
the tests. While the highest requirements is for support of dynamic the tests. While the highest requirements is for support of dynamic
acquisition, CDNI use-cases (defined in acquisition, CDNI use-cases call for support of pre-positioning,
[I-D.bertrand-cdni-use-cases]) call for support of pre-positioning,
which requires a triggering mechanism in a CDNI API. which requires a triggering mechanism in a CDNI API.
3.3.2. Content Purge 3.3.2. Content Purge
CDN technology typically supports APIs allowing content purge in a CDN technology typically supports APIs allowing content purge in a
CDN. However, while often similar, these APIs are proprietary and CDN. However, while often similar, these APIs are proprietary and
would require custom support. For this reason, content purge was not would require custom support. For this reason, content purge was not
covered in the tests. There is a strong requirement for content covered in the tests. There is a strong requirement for content
purge in CDNI scenarios, which introduces the need for a purge purge in CDNI scenarios, which introduces the need for a purge
triggering mechanism in a CDNI API. triggering mechanism in a CDNI API.
4. Acknowledgments 4. Acknowledgments
The authors would like to acknowledge the work of Elodie Hemon and The authors would like to acknowledge the work of Elodie Hemon and
Sharon Schwartzman on the tests. They would like to thank Slim Gara, Marcin Pilarski on the tests, with the technical support of Sharon
Schwartzman and Marc Fiuczynski. They would like to thank Slim Gara,
Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for
valuable input and discussions. Finally, the authors acknowledge valuable input and discussions. Finally, the authors acknowledge
interesting discussions with contributors of the EU FP7 OCEAN interesting discussions with contributors of the EU FP7 OCEAN
project. project.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Security Considerations 6. Security Considerations
skipping to change at page 19, line 35 skipping to change at page 19, line 26
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[I-D.bertrand-cdni-use-cases] [I-D.bertrand-cdni-use-cases]
Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and Bertrand, G., Stephan, E., Watson, G., Burbridge, T.,
P. Eardley, "Use Cases for Content Distribution Network Eardley, P., and K. Ma, "Use Cases for Content Delivery
Interconnection", draft-bertrand-cdni-use-cases-01 (work Network Interconnection", draft-bertrand-cdni-use-cases-02
in progress), January 2011. (work in progress), July 2011.
[I-D.jenkins-cdni-problem-statement] [I-D.jenkins-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", draft-jenkins-cdni-problem-statement-01 (work Statement", draft-jenkins-cdni-problem-statement-02 (work
in progress), January 2011. in progress), March 2011.
[I-D.lefaucheur-cdni-requirements] [I-D.lefaucheur-cdni-requirements]
Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee, Leung, K., Lee, Y., Faucheur, F., Viveganandhan, M., and
"Content Distribution Network Interconnection (CDNI) G. Watson, "Content Distribution Network Interconnection
Requirements", draft-lefaucheur-cdni-requirements-00 (work (CDNI) Requirements",
in progress), January 2011. draft-lefaucheur-cdni-requirements-02 (work in progress),
July 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003. Internetworking (CDI) Scenarios", RFC 3570, July 2003.
Authors' Addresses Authors' Addresses
Gilles Bertrand (editor) Gilles Bertrand (editor)
France Telecom R&D France Telecom - Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange-ftgroup.com Email: gilles.bertrand@orange-ftgroup.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
 End of changes. 46 change blocks. 
83 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/