Internet DRAFT - draft-yang-cdni-rr-foot-cap
draft-yang-cdni-rr-foot-cap
CDNi Y. Yang
Internet-Draft Yale University
Intended status: Informational July 28, 2012
Expires: January 29, 2013
Service Access/Anchor Point (SAP) Based CDN Capacity/QoE Exposure
draft-yang-cdni-rr-foot-cap-00
Abstract
The objective of the Footprint and Capability Interface of CDNi is to
allow a dCDN to expose information to a uCDN so that the uCDN can
select a set of dCDN(s) to delivery contents for content publishers.
In this draft, we propose a flexible approach for a dCDN to expose
its footprint and capabilities based on a generic concept called
Service Access or Anchor Point.
Requirements Language
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].
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 January 29, 2013.
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
Yang Expires January 29, 2013 [Page 1]
Internet-Draft SAP Capacity/Footprint July 2012
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Generic CDN QoE Information Base . . . . . . . . . . . . . . 3
3. Service Access/Anchor Point Based Information Bases . . . . . . 4
4. Additional Information Bases for Request Routing . . . . . . . 6
5. Encoding and Transport of Information Bases . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Yang Expires January 29, 2013 [Page 2]
Internet-Draft SAP Capacity/Footprint July 2012
1. Introduction
There are many recent studies on the Footprint and Capacity Interface
of CDNi. In particular, the semantics draft [] and multiple recent
proposals (e.g., He et al. [], Le Louedec et al. [], Previdi et al.
[], Seedorf [], Song et al. [], Stephan et al. []) provide much
insight on the design of the Capacity and Footprint Interface. In
this draft, we outline one potential design direction to motivate
more discussions on this important interface. The draft is
incomplete and focuses more on the motivation and basic concepts.
2. A Generic CDN QoE Information Base
Our design is based on the following observations/assumptions:
o A major motivation for the adoption of CDN by a Content Publisher
is to provide better quality of experiences (QoE). Hence the
information exposed by a CDN should include delivery QoE, beyond
reachability/willingness.
o The QoE provided by a CDN depends on a set of properties of an End
User (EU) request. One key property of a request is the network
location of the End User (e.g., an IP in North America); another
property is the property of the User Agent (e.g., a mobile device
vs a desktop device); the other set of properties are from the
requested URI (e.g., http, https, rtsp, image, streaming, etc).
o The QoE provided by a CDN also depends on how a CDN handles a
request. In particular, a CDN may provide differentiated
services. For example, a CDN may offer both a Premium service
(i.e., high priority) and an Economy service. Different service
levels from the same CDN may offer different levels of QoE (or
SLA). Advertising different service levels can provide more
flexible uCDN selection.
Given the preceding observations, we may design that a dCDN,
regarding its QoE, offers the following capability/QoE information
structure:
<UserIP, UserAgentProp, ContentProp, CDNServiceCategory> -> QoE metrics.
Figure 1: CDN QoE Raw Table.
Yang Expires January 29, 2013 [Page 3]
Internet-Draft SAP Capacity/Footprint July 2012
3. Service Access/Anchor Point Based Information Bases
The preceding information structure is quite general, but does not
provide enough operational information. In particular, there is no
information for a uCDN to direct a request to a chosen dCDN. Below,
we consider the domain knowledge of CDN request routing to propose
another information structure to convey the same preceding info, with
operational information as well.
Specifically, a generic conceptual framework of a CDN is that it
consists of two types of logical entities: request routers to direct
requests around and surrogate servers to actually serve requests.
Consider a dCDN with a two-level DNS-based request routing system: a
(logical) global DNS request router (say dCDN.com) and multiple
(logical) 2nd level DNS request routers (say east.dCDN.com and
west.dCDN.com). A request (for example, a DNS name resolution) first
arrives at the 1st level request router, who forwards the request to
a chosen 2nd level request router (say east.dCDN.com). Since the
term request router is too entity-oriented (as we see later), we way
that the CDN has three request routing service access/anchor points
(RR-SAP) or service access/anchor points (SAP) for short. In other
words, in this example, the request to the dCDN's request routing
system may visit 3 service access points: 1) protocol=DNS,
server=dCDN.com, query=CP DNS name; 2) protocol=DNS,
server=east.dCDN.com, query=CP DNS name; and 3) protocol=DNS,
server=west.dCDN.com, query=CP DNS name. How a request is forwarded
among the three service access points (e.g., hierarchy, consistent
hashing) is a CDN's internal structure.
To summarize, the framework of CDN RR we use is that a CDN consists
of a set of SAPs, and a set of surrogate servers. One may consider
surrogate as special case SAPS. The objective of RR is to expose
SAPS.
With the introduction of the SAP concept, we now specify a
capability/footprint information structure based on SAP. In
particular, we first introduce two information bases (tables). These
information bases provide not only information in the preceding
section but offer more info for request routing.
o SAP Information Base (SIB): which specifies the information on
each SAP. There can be multiple types of SAPs, e.g., DNS resolver
SAP, IP Anycast SAP, and HTTP load balancer SAP. The SAP
information base specifies information about how to access each
revealed SAP, as well as properties (e.g., cap) of each SAP to the
uCDN. For example, for a DNS SAP, it can be the DNS name (e.g.,
east.dCDN.com) or the IP address. There can be additional
information on how to protect the access to an SAP. Each SAP also
Yang Expires January 29, 2013 [Page 4]
Internet-Draft SAP Capacity/Footprint July 2012
provides an *online (syncrhonous) redirection request point*
(e.g., URI). This point may or may not be the same as SAP contact
server. To summarize, the SAP Information Base is a mapping: SAP
-> SAP name, SAP type, SAP access info.
o SAP QoE Information Base (SQIB): which specifies the QoE and
capability, depending on the access SAP. In other words, the SAP
QoE Information Base is a mapping: <UserIP, SAP> ->
<UserAgentTypeSupported, ContentPropSupported, QoE metrics.
With the preceding information bases, we now consider several example
request routing scenarios. We will start with the simple CDN example
of one 1st level DNS resolver and two 2nd level DNS resolvers. We
use DNS resolvers as example request routers, and one may consider
application (e.g., HTTP) request routers as well.
o Example 1: Generic uCDN. For this example, the dCDN does not want
to reveal the two 2nd level SAPs. Hence, it provides its SIB
containing only one SAP, which is the 1st level. In other words,
the dCDN advertises a single SAP: dCDN.com. The SQIB information
is also based on the generic QoE reachable (e.g., 100 ms) for its
reachable set of IPs.
o Example 2: More Trusting uCDN. For this example, the dCDN may
reveal the 2nd level SAPs, for example to a uCDN with more trust.
Hence, the dCDN advertises its SIB as containing two SAPs: SAP-
EAST (east.dCDN.com) and SAP-WEST (west.dCDN.com). In a more
general case, a dCDN may have a request routing hierarchy and can
selectively reveal the info about SAPs. Such a short-cut in
request routing may reduce latency, as the uCDN can then directly
point a request to a lower level SAP. The QoE indicated then can
be more fine grained. For example, it advertises for SAP-EAST
only the IPs to be served by the east coast and hence tighter QoE.
o Example 3: Differentiated Services. The dCDN may start to offer
two levels of services: say gold and silver or whatever the
marketing term. The dCDN then advertises its SIB containing two
SAPs: SAP-GOLD (gold.dCDN.com) and SAP-SILVER (silver.dCDN.com).
The SQIB indicates different QoEs for the two SAPs. The uCDN may
selectively use one or both SAPs. Note that the Differentiated
Service and the Spatial Refinement in Example 2 can be combined
through defining more SAPs.
o Example 4: Content/User Types. The dCDN may start to offer a
mobile (User Agent) service at a location. The dCDN then
advertises a new SAP (e.g., SAP-MOBILE/mobile.dCDN.com) for this
service and indicates the QoE/UA-Content Type.
Yang Expires January 29, 2013 [Page 5]
Internet-Draft SAP Capacity/Footprint July 2012
o Example 5: External Delegation. The dCDN may delegate a subset of
the requests to another edge CDN say d2CDN. For such a case, if
request routing loop is an issue, the dCDN should define an SAP
for this delegation and reveal the delegation (d2CDN) in the SIB
advertised to uCDN. Note that dCDN may or may not allow shortcut
to d2CDN directly. If not, the revealed SAP DNS resolver is still
within dCDN (e.g., dCDN.com as DNS resolver); if yes, the revealed
SAP DNS resolver can be within d2CDN (e.g., from_d1CDN-auth-
key.d2CDN.com). In both cases, SQIB should reveal the subset of
IPs and the QoE.
o Example 6: External Multipath Delegation. Consider a complex
example that for a subset of IPs. dCDN offers both d2CDN and
d3CDN. d2CDN delegates to d4CDN , and d3CDN delegates to d4CDN as
well. In other words, there are two CDNi delegation paths to the
subset of IPs: dCDn -> d2CDN -> d4CDN; and dCDN -> d3CDN -> d4CDN.
Then dCDN can define 2 SAPs: SAP-d2CDN-d4CDN and SAP-d3CDN-d4CDN
and offer both paths for a uCDN to select. The dCDN may or may
not offer shortcuts, as in the preceding example. As a comparison
between SAP based specification and BGP, SAP provides an ability
for multi-path routing, which can be quite valuable, and BGP
cannot (i.e., BGP cannot announce dCDN->d2CDN->IP and
dCDN->d3CDN->IP for the same IP, because the data path does not
have the mechanism to specify such split.
4. Additional Information Bases for Request Routing
In addition to SAP Information Base (SIB) and SAP QoE Information
Base (SQIB), there are additional information (tables) that if
exchanged, can help a uCDN to select dCDNs for request routing. Here
are some examples:
o GeoMapping Information Base (GIB): a CDN, who owns a subset of
IPs, may have more authoritative information on the geolocation of
the IP.
o Charging Region Information Base (CRIB): Some CDNs (e.g., Amazon)
use the concept of charging regions. Then there is the need of
End User IP to charging region mapping.
5. Encoding and Transport of Information Bases
There are multiple ways to encode the aforementioned information
bases (SIB, SQIB, GIB, and CRIB). One possibility is to base on the
ALTO protocol with extensions. A particular large information that
needs to be encoded is SAP QoE Information Base (SQIB). One can use
Yang Expires January 29, 2013 [Page 6]
Internet-Draft SAP Capacity/Footprint July 2012
the Network Map and Cost Map (SAP -> PID) to encode the information
base, with extensions to handle updates/notification. The details
will need to be determined later. The ALTO protocol, the proposed
CDNI MetaData, and the proposed CDNI Control are use HTTP Restful
Encoding and may form a coherent protocol for CDNI.
6. Security Considerations
To be added.
7. IANA Considerations
This document does not have any IANA considerations.
8. Acknowledgments
To be added.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
Author's Address
Y. Richard Yang
Yale University
Email: yry@cs.yale.edu
Yang Expires January 29, 2013 [Page 7]
