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]