CDNI R. Krishnan
Internet Draft Brocade Communications
Intended status: Informational M. Li
Expires: November 2013 B. Khasnabish
ZTE USA
C. Ge
China Telecom
May 26, 2013
Best practices and Requirements for delivering Long Tail
personalized content delivery over CDN Interconnections
draft-krishnan-cdni-long-tail-05.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November, 2013.
Copyright Notice
Copyright (c) 2013 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) in effect on the date of
publication of this document. Please review these documents
Krishnan Expires November 2013 [Page 1]
Internet-Draft CDNI Long Tail February 2012
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Abstract
The content desire of users is evolving from most popular to long
tail personalized content. This document discusses the best
practices and requirements for delivering long tail personalized
content in CDN Interconnection scenarios.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. No Caching in CDNs.............................................3
4. Benefits of HTTP Adaptive Streaming............................6
5. Other techniques for delivering long tail personalized content.6
6. Acknowledgements...............................................7
7. References.....................................................7
7.1. Normative References......................................7
7.2. Informative References....................................7
1. Introduction
Typically, the CDNI interface between CDNs is a long-haul backbone
network where bandwidth is premium. For user content requests from
the downstream CDN (dCDN), a cache in the dCDN addresses the CDNI
bandwidth challenge by being able to serve the content from the dCDN
and avoiding accessing the content from the upstream CDN (uCDN). The
cache has limited storage space/processing power and relies on the
fact that the same piece of content is of interest to a lot of
users.
Most popular content is of interest to a lot of users; examples are
latest movies, latest catch-up episodes etc. A single copy of the
content is delivered across CDNI to the cache; the content is
Krishnan Expires November 2013 [Page 2]
Internet-Draft CDNI Long Tail February 2012
delivered to multiple users from the cache. Thus, most popular
content is very amenable to caching.
Long tail personalized content is of interest to only a few users;
examples are documentaries, very old movies etc. Long tail
personalized content is typically not shared by many users and
caching of long tail personalized content could lead to cache
thrashing issues. Thus, long tail personalized content is not
amenable to caching.
This document discusses the best practices and requirements for
delivering long tail personalized content in CDN Interconnection
scenarios. This will be pursued further in the second phase of the
CDNI work.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology defined in:
[I-D.ietf-cdni-problem-statement-08],
[I-D.ietf-cdni-requirements-06],
[I-D.ietf-cdni-framework-03], and
[I-D.ietf-cdni-use-cases-10].
3. No Caching in CDNs
Long tail personalized content is typically not shared by many users
and not amenable to caching. Avoiding caching in the CDNs has the
following benefits 1) Better cache utilization 2) Avoid unnecessary
HTTP redirection.
Each CDN has a local monitoring server which monitors the end user
content usage in the CDN. By monitoring the content usage, each CDN
determines whether or not the content should be cached locally in
the CDN. Through the CDNI interface, each dCDN propagates this
information to the uCDN(s). Thus, the uCDN(s) determine the dCDNs in
which the content should be cached/not cached. This results in the
following CDNI metadata interface requirement and request routing
interface changes which are described in this draft.
Krishnan Expires November 2013 [Page 3]
Internet-Draft CDNI Long Tail February 2012
An example interconnected CDN topology is depicted in Figure 1; CDN-
A and CDN-B are uCDNs which have a relationship with the Content
Service Provider(CSP). CDN-C, where the end users are connected, is
a dCDN and has a local monitoring server.
+-------+
| CSP |
+-------+
/ \
,--,--,--./ \,--,--,--.
,-' `-. ,-' `-.
( CDN Provider A ) ( CDN Provider B )
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
\\ //
\\,--,--,--.//
,-' `-.
( CDN Provider C )
`-. (CDN-C) ,-'
`--'--'--'
|
+------------+
| User Agent |
+------------+
=== CDN Interconnect
Figure 1: Interconnected CDNs with one dCDN
Metadata interface requirement
The CDNI Metadata Distribution interface shall provide indication
by the dCDN to the uCDN whether the content should be cached or
not cached in the dCDN. This information should be on a per URL
basis. The default behavior would be to cache the content in the
dCDN
Referring to the example in Fig. 2, Section 3 [I-D.ietf-cdni-
framework]; it shows Operator A as the uCDN and Operator B as the
dCDN, where the former has a relationship with a content provider
and the latter being the best CDN to deliver content to the end-
user. Referring to the HTTP example in Fig. 3, Section 3.2 [I-
D.ietf-cdni-framework];
Request routing interface changes
Krishnan Expires November 2013 [Page 4]
Internet-Draft CDNI Long Tail February 2012
Step 2: A Request Router for Operator A (which is the uCDN)
processes the HTTP request. The HTTP URL metadata is looked up in
a metadata database. For long tail personalized content, the
metadata database lookup result indicates that the content should
not be cached by the dCDN. The Request Router for Operator A
recognizes that the end-user is best served by the uCDN without
any caching the in dCDN and returns a 302 redirect message with
the URL of Operator A delivery node. The end-user proceeds to
retrieve the data from Operator A delivery node. This is
illustrated in Figure 2 below.
End-User Operator B(dCDN) Operator A(uCDN)
|DNS cdn.csp.com | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
| | |
|HTTP cdn.csp.com | |
|-------------------------------------------------->|
| | |(2)
|302 URL of Operator A delivery node |
|<--------------------------------------------------|
| | |
|DNS Operator A delivery node |
|-------------------------------------------------->|
| | |(3)
|IPaddr of Operator A's Delivery Node |
|<--------------------------------------------------|
| | |
|Data Request | |
|-------------------------------------------------->|
| | |(4)
|Data Response | |
|<--------------------------------------------------|
| | |
Figure 2: Request Routing interface for long tail personalized content
Logging and Auditing requirements
Work in progress
Krishnan Expires November 2013 [Page 5]
Internet-Draft CDNI Long Tail February 2012
4. Benefits of HTTP Adaptive Streaming
As discussed before, long tail personalized content is not amenable
to caching. Also, there is heavy asymmetric usage of the network
between peak and quiet hours, where the peak hour load is much
higher than the quiet hour load. These create unique bandwidth
challenges across CDNI. HTTP Adaptive Streaming (HAS), which can
adapt to network congestion, is ideally suited for delivering long
tail personalized content across interconnected CDNs.
5. Other techniques for delivering long tail personalized content
Approach 1
If the uCDN has a charging agreement with the dCDN that the dCDN
pays fixed monthly money to uCDN (no matter how much traffic they
exchange each month) and the CDN has enough storage capacity, the
cache control of the long tail content is not that necessary, but
let each CDN decide whether to cache the content or not locally. If
the user request is redirected to dCDN but the dCDN does not cache
the content, the dCDN can acquire the content from its uCDN.
Approach 2
If static control is desired for long tail content, the CSP can
assign a second-level domain name for such kind of content, e.g.
nocache.example.com/contentID, so that when this content is injected
into CDNI system, CDN would determine whether to cache it or not
according to this domain name.
Approach 3
So far, what has been discussed is streaming delivery of long tail
personalized content. Caching in the end user device is another
technique which can be used to address the bandwidth challenges
created by streaming delivery of long tail personalized content over
CDNI. This introduces a new model for long tail personalized content
delivery. The various components of this model can be defined as
1)End user chooses the content to watch 2) The content is downloaded
in the background and cached in the end user device 3)End user is
notified of content availability. This model is typically applicable
for long form content where the overhead in managing a background
download is justifiable.
Caching in the end user device can have potential DRM issues which
can be addressed using the following techniques 1) The content can
be accessed by the end user only for playback 2) The content has a
Krishnan Expires November 2013 [Page 6]
Internet-Draft CDNI Long Tail February 2012
time expiry after which it destructs itself 3) In the case of end
user device loss, the content destructs itself.
6. Acknowledgements
The authors would like to thank Francois Le Faucheur, Kevin Ma, Jin
Weiyi and Ben Niven-Jenkins for their input.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
7.2. Informative References
[I-D.ietf-cdni-framework]L. Peterson et al., "Framework for CDN
Interconnection", http://www.ietf.org/id/draft-ietf-cdni-framework-
03.txt, February 2013.
[I-D.ietf-cdni-problem-statement]B. Niven-Jenkins et al., "Content
Distribution Network Interconnection (CDNI) Problem
Statement", http://tools.ietf.org/id/draft-ietf-cdni-problem-
statement-08.txt, June 2012, and
http://datatracker.ietf.org/doc/rfc6707/, Sep. 2012.
[I-D.ietf-cdni-requirements]K. Leung et al., "Content Distribution
Network Interconnection (CDNI) Requirements",
http://www.ietf.org/id/draft-ietf-cdni-requirements-06.txt, April
2013.
[I-D.ietf-cdni-use-cases]Bertrand, G. et al., "Use Cases for Content
Delivery Network Interconnection", http://tools.ietf.org/id/draft-
ietf-cdni-use-cases-10.txt, August 2012,
http://datatracker.ietf.org/doc/rfc6770/, November, 2012
Krishnan Expires November 2013 [Page 7]
Internet-Draft CDNI Long Tail February 2012
Authors' Addresses
Ram Krishnan
Brocade Communications
San Jose, 95134, USA
Phone: +001-408-406-7890
Email: ramk@brocade.com
Mian Li
ZTE Corporation
Nanjing, 210012
China
Phone:
Email: li.mian@zte.com.cn
Bhumip Khasnabish
ZTE Corporation
New Jersey, 07960, USA
Phone: +001-781-752-8003
Email: bhumip.khasnabish@zteusa.com, vumip1@gmail.com
Chen Ge
China Telecom
109 West Zhongshan Ave
Guangzhou, Tianhe District, China
Phone:
Email: cheng@gsta.com
Krishnan Expires November 2013 [Page 8]