[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requirements for Content Distribution
In section 3, does the protocol indicate that CDN B is an agent for CDN A, or
does CDN B aggregate messages from its "lefthand" CDN's of surrogates
and promote them rightward as if they originated from CDN B?
There appears to be no required relationship between the capabilities
advertisement and the distribution request. So the capabilities are
simply advisory?
Are the capabilities useful? Presumably the content destination
cares more about hit rate, size, expiration time, etc. than the
content type itself? There's no mention of latency or cost,
the only two bottom line charateristics, when you come right
down to it. Live streaming media probably needs some
different characteristics, which you allude to.
For the "push" URL, can an intermediate agent of the
CDN change this in forwarding it rightward through the
diagram in section 3? If the agent can aggregate,
then the advertisements could get completely rewritten
in passage.
In the confirmation, if there is no limited acceptance, then the
request must exactly match the capabilities of the distribution
network, for which there is no required pre-announcement. This
makes it difficult to get the distribution request right. The more
parameters, the worse it gets.
Presumably a "hash" in the distribution request a bitstring derived
from the (static) content. The hash lets you identify the content
irrespective of location. This would allow the distribution network
to retrieve the content from a non-authoritative source).
Would this be useful?
This leads to a related point: can the authoritative source be a list?
Hilarie
>>> Stephen Thomas <stephen.thomas@transnexus.com> 01/15/01 12:08PM >>>
Here's a first cut at organizing the discussion into a internet draft.
There are lots of holes left to fill and much discussion remaining, but I
thought it worthwhile to try to take a first shot. Comments, flames,
questions, etc. are encouraged. Comments, flames, questions, etc. with
suggested text for the draft are strongly encouraged.
The text below has the pagination stripped out for easier reading and
commenting via email. The attachment has the pagination intact for ease of
printing.
Stephen
<Working Group Name> S. Thomas
Internet Draft TransNexus, Inc.
Document: <draft-wgname-distreqs-xx.txt> January 2001
Category: Informational
Requirements for Content Distribution
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
[In its current state, this document includes many editorial notes
and comments. Such notes and comments are intended to highlight
areas where more details are necessary, or where the editor feels
that the group is far from consensus. Given the preliminary nature
of this draft, it should not be assumed that un-commented aspects of
the document do represent consensus; rather, those aspects appear to
the editor to be nearer consensus. All editorial notes and comments
are enclosed in square brackets such as this.]
This document summarizes the requirements for the content
distribution characteristics of CDN internetworking. For content
distribution, CDNs agree on the exchange of content. Content
distribution (in this limited definition) does not consider how user
agents are directed to rendezvous with the distributed content, nor
how CDNs exchange accounting information related to the access of
distributed content.
Content distribution assumes an architecture in which one CDN has,
or has access to, content, and another CDN has, or has access to,
surrogates on which that content may distributed. The first CDN is
referred to below as the "Content Source," while the second is
referred to as the "Content Destination." Note that the original
content provider is a degenerate case of a CDN content source.
The requirements assume a three-phase approach to content
distribution; however, not all of these phases must necessarily be
supported by communication protocols in all implementations. The
first phase is Destination Capabilities Exchange. During this phase,
the CDN content destination identifies the capabilities of its CDN
distribution services. In the second phase, the CDN content source
requests the use of some (or all) of those services. In the third
phase, the CDN content destination acknowledges (either positively
or negatively) a requested content distribution.
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 [2].
3. Content Distribution Architecture
The architecture for content distribution presumes that even the
most complex communication arrangements may be defined as a simple
interaction between a content destination and a content source. The
following figure, for example, shows a relationship between four
different administrative authorities. CDN A operates a network of
surrogates, and "CDN D"(actually the original content provider) has
content to be distributed. CDN A communicates with CDN B, who
communications with CDN C, who, in turn, communicates with CDN D.
+------------+ +-----------+ +-----------+ +------------+
| CDN A | | CDN B | | CDN C | | "CDN D" |
|(surrogates)|<->| (agent |<->| (agent |<->| (content |
| | | for A) | | for D) | | provider) |
+------------+ +-----------+ +-----------+ +------------+
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
CONTENT DST <-> CONTENT SRC
In each case, one of the parties in the communications has the role
of content destination, while the other party is the content source.
Note that a particular CDN's role may change, depending on the party
with whom it is communicating. CDN B, for example, is a content
source when communicating with CDN A, but a content destination when
communicating with CDN C.
[Ed: I don't think we've ever explicitly talked about this model. It
seems general enough to me to be reasonable, but other opinions are
solicited.]
4. Content Distribution Process
At a high level, the content distribution process proceeds in three
phases. The following sections discuss each phase in more detail. As
an overview, the communicating parties have the following
responsibilities in each phase.
Phase I * Destination Capabilities Exchange. In this phase the
content destination identifies the capabilities of its distribution
service. Note that this phase may not necessarily require a
communications protocol, as it may be handled off-line (e.g. as a
part of contractual negotiations between the parties). [Ed: There
seems to be fairly polarized opinions in the group on this issue.
Some have argued that this phase should be accomplished completely
off-line, while others have identified a need to have support for
this phase in a real-time communications protocol. At this point,
the approach is to define it as a part of the distribution process
so that it can be made an optional part of any communication
protocols.]
Phase II * Distribution Request. In this phase the content source
asks the content destination to distribute its content.
Phase III * Distribution Confirmation. In this, the final
distribution phase, the content destination confirms its acceptance
(or denial) of the distribution request. Note that this phase does
not provide any information about whether the distributed content
has been accessed by user agents; such information exchange is the
responsibility of CDN accounting. [Ed. Although there has been some
discussion as to whether this phase is necessary, the editor feels
that such questions were due mainly to a misunderstanding of the
purpose of the confirmation. Corrections to this assumptions are
solicited.]
5. Phase I - Destination Capabilities Exchange
In the destination capabilities exchange, the content destination
identifies the capabilities of its CDN service. Those capabilities
may be defined as combinations of one or more of the following
attributes [Ed: in no particular order]:
Footprint: The areas served by the CDN, expressed as one or more
CIDR IP address prefixes. [Ed: There has been the suggestion
to use a generic attribute for footprint instead of IP address
prefixes, but the editor has not (yet?) sensed much support
for this proposal.] [Ed: It has been noted by many that IP
address prefixes do not necessarily have a strong correlation
to geographic areas, and, in some cases, it may be more
desirable to express footprint as geographic areas; however,
the editor is not aware of any concrete proposal to express
geographic areas.] [Ed: The editor does not sense a consensus
on whether or not it is necessary for a CDN that advertises a
particular footprint to actually control surrogates on that
subnet, or whether it is sufficient for the CDN to simply be
willing to respond to requests from the indicated subnet.]
Content Type: The type of content (e.g. static Web pages,
streaming media, etc.) that the CDN is willing to distribute.
[Ed: Presumably, this is expressed as an IANA-registered media
type, but this has not been discussed on the list.]
Capacity: The storage capacity that the CDN can provide. [Ed:
Some discussion as to whether this is useful, but, so long as
it is optional, is there a problem including it?]
Bandwidth: The bandwidth available from the CDN. [Ed: Some
discussion as to whether this is useful, but, so long as it is
optional, is there a problem including it?]
Distribution Method: The distribution methods that the CDN
supports; one or more of push, pull, and on-demand.
Private Extensions: Additional metrics that the communicating
parties may agree to use, but are not part of the IETF
standard.
[Ed: Cost has also been proposed as an attribute but the editor
feels that it cannot be reasonably accommodated in a standard;
contrary opinions are solicited.]
[Ed: The following has not been the subject of list discussion, so
the editor may be assuming to much to include it at this point;
however, it is presented in the spirit of fostering discussion.]
Destination capabilities are expressed as a combination of the above
attributes. So, for example, a CDN might advertise the following
capabilities:
172.16.0.0/16; text/html,image/gif; 100 GB; 1 Gbit/s; pull
10.1.2.0/24; text/html; 200 GB; 100 Mbit/s; push:URL
10.1.2.0/24; video/quicktime; 0 GB; 256 Mbit/s; on-demand
Such a list indicates that the CDN is willing to distribute up to
100 GB of static web content (either HTML pages or GIF images) to
the 172.16.x.x subnet, to which it has 1 Gbit/s connectivity; the
CDN will pre-fetch (pull) any such content. In addition, the CDN is
willing to distribute up to 200 GB of HTML pages to the 10.1.2.x
subnet, to which it has 100 Mbit/s of connectivity; the CDN requests
that such content be pushed by the content provider to the indicated
URL. Finally, the CDN is also willing to distribute Quicktime videos
on-demand to the 10.1.2.x subnet; the CDN can provide up to 256
Mbit/s of bandwidth for such content. In this last case, the content
will be pulled from the content provider on-demand, and not stored
in the CDN's caches. [Ed: This last example intends to represent
streaming media.]
Note that this phase need not always be accomplished by a real-time
communication protocol. In some implementations, it may be
sufficient for the parties to establish the destination's
capabilities off-line.
6. Phase II * Distribution Request
In the second phase of content distribution, the content source
requests distribution of its content. It describes that content with
one or more of the following attributes [Ed: in no particular
order]:
URI: The uniform resource identifier for the content. [Ed: The
editor would prefer further discussion on whether this
attribute must uniquely identify an atomic unit of content or
whether it can more generally specify a URI path. Allowing
paths may significantly reduce the size of any protocol
transfers, but, there are some attributes (e.g. size, content
type) that do not apply as cleanly to paths, and some
distribution methods (e.g. pull) cannot be easily accommodate
paths.] [Ed: The suggestion has also been made to specify a
"hash" rather than a URI, but the editor lacks sufficient
understanding of that approach to document it.]
Authoritative Source: Unique identity of the authoritative source
for the content.
Content ID: A unique identifier for this specific content, so
that future references (e.g. to modify the content or to
withdraw it from distribution) may be resolved. This value can
also be used to avoid loops. [Ed: a "path" attribute has also
been proposed as a way to avoid loops, but the editor feels
such an attribute is unnecessary; contrary opinions are
solicited.]
Distribution Method: Push, pull, on-demand, or withdraw. How the
content destination should retrieve the content. Withdraw is a
special case that indicates a content destination should cease
distribution of previously accepted content.
Size: Size of the content. [Ed: No consensus that this is
required, but any problems making it optional?]
Time Frame: The period of time for which the content source
requests distribution. [Ed: No consensus that this is
required, but any problems making it optional?]
[Ed: Next Hop has also been proposed as an attribute, but the
editor lacks sufficient understanding to describe it; clue
injections are solicited.]
[Ed: Metric has also been proposed as an attribute, but the
editor lacks sufficient understanding to describe it; clue
injections are solicited.]
7. Phase III * Distribution Confirmation
In the final phase, the content destination accepts or rejects the
distribution request. [Ed: There has some been some discussion about
partial acceptance, e.g. only for a limited time or only a limited
capacity, but the editor does not (yet?) sense a consensus that such
a response is practical or useful.]
8. Security Considerations
To be provided.
9. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
10. Acknowledgments
To be provided.
11. Author's Addresses
Stephen Thomas
TransNexus, Inc.
1140 Hammond Drive, Building E
Suite 5250
Atlanta, GA 30328
Phone: +1 770 671 1888
Email: stephen.thomas@transnexus.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into