CDNI R. van Brandenburg
Internet-Draft O. van Deventer
Intended status: Informational TNO
Expires: August 27, 2012 February 24, 2012
Models for adaptive-streaming-aware CDN Interconnection
draft-brandenburg-cdni-has-00
Abstract
This documents presents thougths on the potential impact of
supporting HTTP Adaptive Streaming technologies in CDN
Interconnection scenarios. Our intent is to spur discussion on how
the different CDNI interfaces should deal with content delivered
using adaptive streaming technologies.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2012.
Copyright Notice
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include 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.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 1]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. HTTP Adaptive Streaming aspects relevant to CDNI . . . . . . . 4
2.1. Segmentation versus Fragmentation . . . . . . . . . . . . 4
2.2. Addressing chunks . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Full Locator . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Relative Locator . . . . . . . . . . . . . . . . . . . 7
2.2.3. Chunk Request Routing . . . . . . . . . . . . . . . . 7
3. Impact of HAS on CDNI . . . . . . . . . . . . . . . . . . . . 8
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. On the definition of a Content Item in CDNI . . . . . 8
3.1.2. General CDNI-HAS Requirements . . . . . . . . . . . . 10
3.2. Impact on Request Routing Interface . . . . . . . . . . . 10
3.2.1. Dealing with manifest files . . . . . . . . . . . . . 10
3.2.2. HAS Request Routing . . . . . . . . . . . . . . . . . 11
3.2.3. Dividing content over multiple nodes . . . . . . . . . 12
3.2.4. HAS Requirements for the CDNI Request Routing
Interface . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Impact on Metadata Interface . . . . . . . . . . . . . . . 12
3.3.1. HAS-specific Metadata . . . . . . . . . . . . . . . . 12
3.3.2. HAS Requirements for the CDNI Metadata Interface . . . 13
3.4. Impact on Logging Interface . . . . . . . . . . . . . . . 13
3.4.1. Log processing . . . . . . . . . . . . . . . . . . . . 13
3.4.2. HAS Requirements for the CDNI Logging Interface . . . 14
3.5. Impact on Control Interface . . . . . . . . . . . . . . . 14
3.5.1. HAS Requirements for the CDNI Control Interface . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
van Brandenburg & van Deventer Expires August 27, 2012 [Page 2]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
1. Introduction
HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-
based streaming technologies that allow a client to adaptively switch
between multiple bitrates depending on current network conditions. A
defining aspect of HAS is that, since it is based on HTTP, it is a
session-less pull-based mechanism, with a client actively requesting
content segments, instead of the content being pushed to the client
by a server. Due to this session-less nature, media servers
delivering content using HAS often show different characteristics
when compared with media servers delivering content using traditional
streaming methods such as RTP/RTSP, RTMP and MMS. This document
presents a discussion on what the impact of these different
characteristics is to the CDNI interfaces. The scope of this
document is explicitely not to define solutions, but merely to
identify different methods of handling HAS in a CDN and the potential
problems when using HAS in a CDNI context. The issues identified in
this document may be used as input for defining HAS-specific
requirements for the CDNI interfaces.
1.1. Terminology
This document uses the terminology defined in
[I-D.ietf-cdni-problem-statement].
In addition, the following terms are used throughout this document:
Content Item: A uniquely adressable content element in a CDN. A
content item is defined by the fact that it has its own Content
Metadata associated with it. It is the object of a request routing
operation in a CDN. An example of a Content Item is a video file/
stream, an audio file/stream or an image file. For a discussion on
what may constitute a Content Item with regards to HAS, see section
3.1.1.
Chunk: A fixed length element that is the result of a segmentation or
fragmentation operation being performed on a single encoding of the
Original Content. A chunk is independently, and uniquely,
addressable. Depending on the way a Chunk is stored, it may also be
referred to as a Segment or Fragment.
Fragment: A specific form of chunk (see section 2.1). A fragment is
stored as part of a larger file that includes all chunks that are
part of the Chunk Collection.
Segment: A specific form of chunk (see section 2.1). A segment is
stored as a single file from a file system perspective.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 3]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
Original Content: Unchunked content that is the basis for a
segmentation of fragmentation operation. Based on Original Content,
multiple alternative encodings, resolutions or bitrates may be
derived, each of which may be fragmented or segmented.
Chunk Collection: The set of all chunks that are the result of a
single segmentation or fragmentation operation being performed on a
single encoding of the Original Content. A Chunk Collection is
described in a manifest file.
Content Collection: The set of all Chunk Collections that are derived
from the same Original Content. A Content Collection may consist of
multiple Chunk Collections, each being a single encoding, or variant,
of the Original Content. A Content Collection may be described by
one or more manifest files.
Manifest File: A manifest file, also referred to as Media
Presentation Description (MPD) file, is a file that list the way the
content has been chunked and where the various chunks are located (in
the case of segments) or how they can be addressed (in the case of
fragments).
2. HTTP Adaptive Streaming aspects relevant to CDNI
In the last couple of years, a wide variety of HAS-like protocols
have emerged. Among them are proprietary solutions such as Apple's
HTTP Live Streaming (HLS), Microsoft's Smooth Streaming (MSS) and
Adobe's HTTP Dynamic Streaming (HDS), and various standardized
solutions such as 3GPP AHS (AHS) and MPEG DASH (DASH). While all of
these technologies share a common set of features, each has its own
defining elements. This chapter will look at some of the differences
between these technologies and how these differences might be
relevant to CDNI. In particular, section 2.1 will describe the
various methods to store HAS content and section 2.2 will list three
methods that are used to address HAS content in a CDN.
2.1. Segmentation versus Fragmentation
All HAS implementations are based around a concept referred to as
chunking: the concept of having a server split content up in numerous
fixed length chunks, which are independently decodable. By
sequentially requesting and receiving chunks, a client can recreate
and play out the content. An advantage of this mechanism is that it
allows a client to seamlessly switch between different encodings of
the same Original Content. Before requesting a particular chunk, a
client can choose between mulitple alternatives of the same chunk,
irrespective of the encoding of the chuncks it has requested earlier.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 4]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
NOTE: The set of all chunks belonging to a single encoding, and thus
the result of a single chunking operation, will from now on be
referred to as a Chunk Collection. The set of all encodings of the
same Original Content will be referred to as a Content Collection. A
Content Collection can therefore consist of multiple Chunk
Collections.
While every HAS implementation uses some form of chunking, not all
implementations store the resulting chunks in the same way. In
general, there are two distinct methods of performing chunking and
storing the results: segmentation and fragmentation.
- With segmentation, which is for example mandatory in all versions
of HLS prior to version 7, the chunks, in this case also referred
to as segments, are stored completely independent from each other,
with each segment being stored as a seperate file from a file
system perspective. This means that each segment has its own
unique URL with which it can be retrieved.
- With fragmentation (or virtual segmentation), which is for example
used in Microsoft's Smooth Streaming, all chunks, or fragments,
belonging to the same Chunk Collection are stored together, as
part of a single file. While there are a number of container
formats which allow for storing this type chunked content,
Fragmented MP4 is most commonly used. With fragmentation, a
specific chunk is adressable by subfixing the common file URL with
an identifier uniquely identifying the chunk one is interested in,
either by timestamp, by byterange, or in some other way.
While one can argue about the merits of each of these two different
methods of handling chunks, both have their advantages and drawbacks
in a CDN environment. For example, fragmentation is often regarded
as a method that introduces less overhead, both from a storage and
processing perspective. Segmentation on the other hand, is regarded
as being more flexible and efficient with regards to caching. In
practice, current HAS implementations increasingly support both
methods.
2.2. Addressing chunks
In order for a client to request chunks, either in the form of
segments or in the form of fragments, it needs to know how the
content has been chunked and where to find the chunks. For this
purpose, most HAS protocols use a concept that is often referred to
as a manifest file (also known as Media Presentation Description, or
MPD): a file that lists the way the content has been chunked and
where the various chunks are located (in the case of segments) or how
they can be addressed (in the case of fragments). A manifest file,
van Brandenburg & van Deventer Expires August 27, 2012 [Page 5]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
or set of manifest files, may also identify the different encodings,
and thus Chunk Collections, the content is available in.
In general, a HAS client will first request and receive a manifest
file, and then, after parsing the information in the manifest file,
proceed with sequentially requesting the chunks listed in the
manifest file. Each HAS implementation has its own manifest file
format and even within a particular format there are different
methods available to specify the location of a chunk.
Of course managing the location of files is a core aspect of every
CDN, and each CDN will have its own method of doing so. Some CDNs
may be purely cache-based, with no higher-level knowledge of where
each file resides at each instant in time. Other CDNs may have
dedicated management nodes which, at each instant in time, do know at
which servers each file resides. The CDNI interfaces designed in the
CDNI WG will probably need to be agnostic to these kinds of CDN-
internal architecture decisions. In the case of HAS there is a
strict relationship between the location of the content in the CDN
(in this case chunks) and the content itself (the locations specified
in the manifest file). It is therefore useful to have an
understanding of the different methods in use in CDNs today for
specifying chunk locations in manifest files. The different methods
for doing so are described in sections 2.2.1 to 2.2.3.
Although these sections are especially relevant for segmented
content, due to its inherent distributed nature, the discussed
methods are also applicable to fragmented content. Furthermore, it
should be noted that the methods detailed below for specifying
locations of content items in manifest files do not only relate to
temporally segmented content (e.g. segments and fragments), but are
also relevant in situations where content is made available in
multiple qualities, encodings, or variants. In this case the content
consists of multiple chunk collections, which may be described by
either a single manifest file or multiple interrelated manifest
files. In the latter case, there may be a high-level manifest file
describing the various available bitrates, with URLs pointing to
seperate manifest files describing the details of each specific
bitrate. For specifying the locations of the other manifest files,
the same methods apply that are used for specifying chunk locations.
2.2.1. Full Locator
One method for specifying locations of chunks (or other manifest
files) in a manifest file is through the use of a Full Locator. A
Full Locator takes the form of an URL and is defined by the fact that
it directly points to the specific chunk on the actual the server
that is expected to deliver the requested chunk to the client.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 6]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
An example of a Full Locator is the following:
http://deliverynode.server.cdn.com/content_1/segments/
segment1_1.ts
As can be seen from this example URL, the URL includes both the
identifier of the requested segment (in this case segment1_1.ts), as
well as the server that is expected to deliver the segment (in this
case deliverynode.server.cdn.com). With this, the client has enough
information to directly request the specific segment from the
specified delivery node.
2.2.2. Relative Locator
Another method for specifying chunk locations in a manifest file is
through the use of Relative Locator. A Relative Locator is a pointer
that is relative to the location where the manifest file has been
acquired from. In most cases a Relative Locator will take the form
of a string that has to be appended to the location of the manifest
file to get the location of a specific chunk. This means that in the
case a manifest with a Relative Locator is used, all chunks will be
delivered by the same delivery node that delivered the manifest file.
A Relative Locator will therefore not include a hostname.
For example, in the case a manifest file has been requested (and
received) from
http://deliverynode.server.cdn.com/content_1/manifest.xml, a Relative
Locator pointing to a specific segment referenced in the manifest
might be:
segments/segment1_1.ts
Which means that the client should take the location of the manifest
file and append the Relative Locator. In this case, the segment
would then be requested from
http://deliverynode.server.cdn.com/content_1/segments/segment1_1.ts
2.2.3. Chunk Request Routing
A final method for specifying chunk locations in a manifest file is
through the use of request routing. In this case, chunks are handled
by the request routing system of a CDN just as if they were 'normal'
content items. A chunk request comes in at a central request routing
node and is handled just as if it were a regular content request,
which might include looking up the delivery node best suited for
delivering the requested chunk to the particular user and sending an
HTTP redirect to the user with the URL pointing to the requested
chunk on the specified delivery node.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 7]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
An example of an URL pointing to a redirection mechanism might look
as follows:
http://requestrouting.cdn.com/
content_request?content=content_1&segment=segment1_1.ts
As can be seen from this example URL, the URL includes a pointer to a
general CDN request routing function and includes some arguments
identifying the requested segment.
3. Impact of HAS on CDNI
In the previous chapter, some of the unique properties of HAS have
been discussed. Furthermore, some of the CDN-specific design
decision with regards to addressing chunks have been detailed. In
this chapter, the impact of supporting HAS in CDNI will be discussed.
The scope of this chapter is explicitely not to define solutions, but
merely to identify potential problems and issues that need to be
agreed on. For this purpose, each subsection will pose a number of
open questions that will need to be answered by the CDNI WG. At a
later stage, the answers to these questions may be used to solicit
HAS-related requirements for the CDNI Interfaces.
The chapter is divided into three subsections. The first subsection,
3.1, will discuss the impact supporting HAS has on the general CDNI
architecture, use cases and requirements. The other four
subsections, 3.2 to 3.5, will discuss the impact of HAS on each of
the four CDNI Interfaces.
3.1. General
This section will discuss the impact supporting HTTP Adaptive
Streaming has on the general CDNI architecture, use cases and
requirements.
3.1.1. On the definition of a Content Item in CDNI
[I-D.ietf-cdni-problem-statement] defines content as
Content: Any form of digital data. One important form of content
with additional constraints on distribution and delivery is
continuous media (i.e. where there is a timing relationship
between source and sink).
This very broad definition of content is useful for generalizing the
CDNI interfaces in a way that allows them to be agnostic to the type
of content that is delivered. However, what a Content Item in a CDN
van Brandenburg & van Deventer Expires August 27, 2012 [Page 8]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
constitutes may become relevant in the context of HAS if one
considers a Content Item to be the element with which Content
Metadata is associated, and the element that is the object of a
CDN(I) request routing operation.
An example of a Content Item in the general sense is a video file or
stream, such as a TV show or movie, or an audio file, such as an MP3.
In a simple case, a single MP3 is a single Content Item. In a more
complex case, a particular piece of content is made available in
multiple resolutions, languages or qualities. A video item, for
example, might be made available in three different resolutions. In
these cases, it depends on the datamodel of a particular CDN (or a
particular Content Provider) how it defines a Content Item. In some
CDNs, all three video files might be seen as seperate Content Items,
each with their own set of Content Metadata. In other CDNs, the
three alternative encodings of the same content are seen as a single
Content Item, with a single set of Content Metadata describing that
the content consists of three different versions. The CDNI
Interfaces defined in the CDNI WG are affected by these kinds
differences in the ways different CDNs work and might need to be
agnostic to these kinds of CDN-internal (or even Content Provider-
related) decisions.
For content delivered using HAS, there is an even wider variety in
the way different CDNs might interpret the definition of a Content
Item. For example, CDNs using the Relative Locator method (see
section 2.2.2) in their manifest files, might define all chunks that
are part of the same Content Collection, and therefore referenced in
the same (set of) manifest file(s), as a single Content Item for the
purposes of Content Metadata and request routing. Other CDNs might
define all chunks related to a single encoding of a particular video
item, and thus part of the same Chunk Collection, as a single Content
Item, thereby having multiple inter-related Content Items which are
part of the same 'parent' Content Item. Yet another group of CDNs,
especially those using the Chunk Request Routing method (see Section
2.2.3), might define every individual chunk as a seperate Content
Item, with a seperate set of metadata describing each chunk.
In order for the CDNI WG to realise a standardized method of dealing
with metadata, logging and request routing, it will be important to
first have a common understanding of the term Content Item, and what
it constitutes, especially with regard to HAS. One option would be
to not impose a specific model, but allow the CDNI interfaces to
support all the different definitions of Content Item (i.e. from
considering each chunk to be a Content Item to considering all chunks
originating from the same Original Content, and thus part of the same
Content Collection, to be a single content item).
van Brandenburg & van Deventer Expires August 27, 2012 [Page 9]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
o Should the CDNI Interfaces be agnostic to the definition of a
Content Item in a particular CDN?
And if this is not the case, then
o What constitutes a Content Item for the purposes of associating
metadata and request routing?
o How does the definition of a Content Item relate to Chunks, Chunk
Collections and Content Collection?
If the WG decides to not impose a specific definition of what
constitutes a Content Item, it is for further study whether it is
required for all parties involved in the delivery of a single video
item, CSP, uCDN and dCDN, to use the same definition. For example,
is it possible for the uCDN to define a complete Content Collection
as a single Content Item, but for the dCDN which delivers the actual
content to see each chunk as a seperate Content Item and handle the
metadata accordingly?
o Is it necessary for all CDNs involved in the delivery of a single
video item to use the same definition of a Content Item (e.g. can
the uCDN define a Content Collection as a Content Item and the
dCDN define a chunk as a Content Item)?
3.1.2. General CDNI-HAS Requirements
This section is a placeholder for HAS-specific CDNI requirements that
are not related to a specific CDNI interface.
3.2. Impact on Request Routing Interface
This section will discuss the impact supporting HTTP Adaptive
Streaming has on the CDNI Request Routing Interface.
3.2.1. Dealing with manifest files
In section 2.2, three different methods for identifying and
addressing chunks from within a manifest file were described: Full
Locators, Relative Locators and Chunk Request Routing. Of course not
every current CDN will use and/or support all three methods. Some
CDNs may only support one of the three methods, while others may
support two or all three.
The question is whether all CDNs involved in the delivery of a single
video item need to support the same method. Is it for example
possible for a dCDN to use Chunck Request Routing while the uCDN uses
Full Locators? This question boils down to the more fundamental
van Brandenburg & van Deventer Expires August 27, 2012 [Page 10]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
question of who manages manifest file. Should a dCDN be allowed to
change a manifest file? Or even create a new one?
o Should the CDNI Interfaces be agnostic to the way chunks are
identified in the manifest file and requested by the client?
o Should it be possible for a uCDN and dCDN to use two different
methods of addressing chunks in manifest files?
And, related to this
o Should a dCDN be able to adapt a manifest file (i.e. is a manifest
file part of the content, and therefore by definition not
adaptable, or is it part of the delivery method) ?
If the CDNI WG decides that the anwer to these questions is negative,
this will probably mean that the only supported method for Chunk
Adressing is using Relative Locators. For both Full Locators as well
as Chunk Request Routing, it is necessary for the delivering CDN to
change the URLs specified in the manifest file.
3.2.2. HAS Request Routing
One of the essential questions relating to HAS and request routing is
whether CDNI request routing is handled on a per chunk level, a per
Content Collection level, or somewhere in between. This question is
tightly related to the definition of a Content Item, discussed in
section 3.1.1. If a Content Item is the object of request routing,
then it depends on the definition of a Content Item what type of
content element is being request routed.
o Should the CDNI Interfaces specify what element of a HAS stream is
being request routed (i.e. should the CDNI interfaces support per-
chunk request routing) ?
While having a seperate request routing operation for every chunk
will probably not be very efficient, only allowing for entire Content
Collections to be request routed is very limiting. For example, it
might be efficient for a dCDN targeted at mobile devices to only host
(and thus be able to deliver) the lower resolution encodings of a
given video item. In this case it probably wouldn't make sense to
force the mobile CDN to host all resolutions (including the very high
ones with multi-channel audio) that are hosted by the uCDN since
there will be no clients accessing the high resolution content
through the mobile CDN.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 11]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
o Should it be possible for a dCDN to host (and deliver) only a
subset of all the chunks, or chunk collections, of a given Content
Collection?
3.2.3. Dividing content over multiple nodes
An aspect that is related to the issues discussed in sections 3.2.1
and 3.2.2, is that of dividing content over multiple delivery nodes.
In non-cache-based CDNs, where the location of content on delivery
nodes is managed by a centralized process and where content is often
pre-positioned, different Chunk Collections belonging to the same
Content Collection, or even different chunks belonging to the same
Chunk Collection, may be distributed over different delivery nodes.
For example, the most popular resolutions of a particular Content
Collection may be hosted on more delivery nodes than the less popular
resolutions. In order to allow for this kind of internal CDN
optimization it is necessary that the dCDN is able adapt the manifest
file.
o Should it be possible for a dCDN to distribute the chunks, or
Chunk Collections, constituting a given Content Collection over
its delivery nodes?
3.2.4. HAS Requirements for the CDNI Request Routing Interface
This section is a placeholder for HAS-specific requirements for the
CDNI Request Routing interface.
3.3. Impact on Metadata Interface
This section will discuss the impact supporting HTTP Adaptive
Streaming has on the CDNI Metadata Interface.
3.3.1. HAS-specific Metadata
In section 3.1.1, the impact of HAS on the definition of a Content
Item, and what constitutes a Content Item was discussed. More
specifically, it was discussed how different CDNs might see chunks or
chunk collections as Content Items or as parts of Content Items.
This question also has an effect on the way the CDNI Metadata
Interface. If one defines a Content Item as the CDN element with
which Content Metadata is associated, this raises the question how
Content Metadata is associated with HAS content. For example, is
there specific metadata element associated with each chunk, with each
chunk collection, with each content collection, or is there a
specific form of metadata for HAS content?
van Brandenburg & van Deventer Expires August 27, 2012 [Page 12]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
o Is Content Metadata associated with Content Collections, Chunk
Collections or chunks?
o Is it necessary to extend the CDNI Metadata model with HAS-
specific extensions?
3.3.2. HAS Requirements for the CDNI Metadata Interface
This section is a placeholder for HAS-specific requirements for the
CDNI Metadata interface.
3.4. Impact on Logging Interface
This section will discuss the impact supporting HTTP Adaptive
Streaming has on the CDNI Logging Interface.
3.4.1. Log processing
One aspect of using HAS in a CDN context that has been getting a lot
of attention is logging. In contrast to other streaming solutions
which are either session-based (e.g. RTP) or using a single file
(e.g. Progressive Download), the chunked nature of HAS means that
regular logging methods that simply log each content request will
generate extremely large log files with a seperate entry for each
chunk being accessed. Apart from the large file size of these log
files, a further problem is that due to the distributed nature of
these log entries it can be difficult to trace them back to a
specific number of clients or users, which makes reporting difficult.
For this reason, some CDNs use dedicated log processing software
which accumulates, processes and aggregates log files. This log
processing software is a further element where different CDNs might
have different approaches. For example, some CDNs might do the log
processing at a low-level, such as real-time in the delivery nodes.
Other CDNs might process the log files in batches at a centralized
location, such as once every hour or every day.
For the CDNI Logging interface, it will be necessary to realise a
common understanding on what type of logging information is passed
between the uCDn and the dCDN in the case a HAS-like protocol is used
for delivery. Ideally, this interface is agnostic to the CDN-
internal method of log processing. However, this might not be
possible. For example, it can be argued that for transparency
reasons, it is necessary for the dCDN to communicate the raw log
files back to the uCDN. On the other hand, this creates a very large
overhead in the inter-CDN communication, with log files for popular
content possibly exceeding the file size of the content itself.
Another method would be to require the dCDN to aggregate the log
van Brandenburg & van Deventer Expires August 27, 2012 [Page 13]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
files before reporting back to the uCDN, however this would require
the dCDN to have specific log processing software.
o Should the CDNI Logging Interface define a specific log-file
format to be used for HAS content?
3.4.2. HAS Requirements for the CDNI Logging Interface
This section is a placeholder for HAS-specific requirements for the
CDNI Logging interface.
3.5. Impact on Control Interface
This section will discuss the impact supporting HTTP Adaptive
Streaming has on the CDNI Control Interface.
NOTE: At this point the impact of HAS on the CDNI Control Interface
has not yet been determined.
3.5.1. HAS Requirements for the CDNI Control Interface
This section is a placeholder for HAS-specific requirements for the
CDNI Control interface.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
TBD.
6. References
6.1. Normative References
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement, draft-ietf-cdni-problem-statement-03",
January 2012.
van Brandenburg & van Deventer Expires August 27, 2012 [Page 14]
Internet-Draft HTTP Adaptive streaming and CDNI February 2012
[I-D.ietf-cdni-use-cases]
Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T.,
Eardley, P., and K. Ma, "Use Cases for Content Delivery
Network Interconnection, draft-ietf-cdni-use-cases-03",
January 2012.
6.2. Informative References
[Anchor] "".
Authors' Addresses
Ray van Brandenburg
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
M. Oskar van Deventer
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31-88-866-7000
Email: oskar.vandeventer@tno.nl
van Brandenburg & van Deventer Expires August 27, 2012 [Page 15]