Network Working Group K. Ma Internet-Draft R. Nair Intended status: Informational Azuki Systems, Inc. Expires: September 8, 2011 March 7, 2011 Content Distribution Network Interconnection (CDNI) Publisher Use Cases draft-ma-cdni-publisher-use-cases-00 Abstract Content publishers are increasingly using multiple CDNs to publish content to the consumers. It is important to take into account their specific requirements with respect to workflow restrictions with respect to content licensing rules. Also, certain content applications have specific delivery requirements that need to considered while negotiating or signaling inter-CDN arrangements. This contribution highlights some of these use cases to help motivate discussion. 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 July 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Ma, et al. Expires September 8, 2011 [Page 1] Internet-Draft CDNI Publisher Use Cases March 2011 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. Ma, et al. Expires September 8, 2011 [Page 2] Internet-Draft CDNI Publisher Use Cases March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. CDNI Model and CDNI APIs . . . . . . . . . . . . . . . . . . . 5 3. Workflow Management Use Cases . . . . . . . . . . . . . . . . . 7 3.1. Asymmetric Content Availability Use Case . . . . . . . . . 7 3.2. Content Purge Use Case . . . . . . . . . . . . . . . . . 7 3.3. Service Level Agreement Negotiation Use Case . . . . . . 8 4. Detailed Content Delivery Use Cases . . . . . . . . . . . . . . 8 4.1. Grouped File Delegation . . . . . . . . . . . . . . . . . 8 4.2. Adaptive Bitrate Streaming Use Case . . . . . . . . . . . 9 4.3 Session Shifting Use Case . . . . . . . . . . . . . . . . 9 4.4 Origin Server Failover Use Case . . . . . . . . . . . . 10 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Ma, et al. Expires September 8, 2011 [Page 3] Internet-Draft CDNI Publisher Use Cases March 2011 1. Introduction Many use cases for CDN Interconnection are discussed in [I- D.bertrand-cdni-use-cases] from the viewpoint of the CDSP. However, with the growing popularity of over-the-top (OTT) delivery, many content providers (CP) are now choosing to run their own service, without operating their own CDN. The CP may contract and manage multiple CDNs, as opposed to selecting an "Authoritative CDN" to manage CDN delegation, as described in [I-D.bertrand-cdni-use-cases]. This draft takes the viewpoint of these CPs using a federation of CDNs. This document provides additional use cases addressing the needs of workflow management agents (WMA), as they manage multiple Authoritative CDNs. More detailed use cases for unique content delivery scenarios for CPs and end users (EU) are also provided. 1.1. Terminology This document uses the terminology defined in section 1.1 of [I-D.jenkins-cdni-problem-statement] and [I-D.bertrand-cdni-use-cases]. Ma, et al. Expires September 8, 2011 [Page 4] Internet-Draft CDNI Publisher Use Cases March 2011 2. CDNI Model and CDNI APIs For convenience Figure 1 from [I-D.jenkins-cdni-problem-statement] illustrating the CDNI problem area and the CDNI APIs is replicated below with the addition of the workflow management component. Ma, et al. Expires September 8, 2011 [Page 5] Internet-Draft CDNI Publisher Use Cases March 2011 ------- ------- / \ / \ | CSP |***********| WMA | \ / \ / ------- ------- * # # # * # # # * # # # /\ * # # # / \ --------------------- # # # |CDNI| --------------------- / Upstream CDN \ # # # | | / Downstream CDN \ | +-------------+ | # # # Control API | +-------------+ | | |CDN Control |<======#===|====|=======>| CDN Control | | | +------*-*-*--+ | # # | | | +-*-*-*-------+ | | * * * | # # | | | * * * | | +------*------+ | # # Logging API | +-----*-------+ | | ****| Logging |<====#=====|====|=======>| Logging |**** | | * --------------+ | # | | | +-------------+ * | | * * * | # | | | * * * | | * +--------*----+ | # Req-Routing API | +---*---------+ * | | * **|Req-Routing |<==========|====|=======>| Req-Routing |** * | | * * +-------------+ | # | | | +-------------+ * * | | * * * | # | | | * * * | | * * +----------*--+ | # CDNI Metadata API| +-*-----------+ * * | | * * |Distribution |<==#=======|====|=======>| Distribution| * * | | * * | | | \ / | | | * * | | * * | +---------+ | | \/ | | +---------+ | * * | | * ****| | | | | | | |**** * | | ******|Surrogate|*****************************|Surrogate|****** | | | +---------+ | | Acquisition | | +-----*---+ | | | +-------------+ | | +-------*-----+ | \ / \ * / --------------------- ---------*----------- * * Delivery * +------+ | User | | Agent| +------+ <==> interfaces inside the scope of CDNI **** interfaces outside the scope of CDNI #### interfaces important to Workflow Management Agents Figure 1: CDNI Model and CDNI APIs Ma, et al. Expires September 8, 2011 [Page 6] Internet-Draft CDNI Publisher Use Cases March 2011 3. Workflow Management Use Cases This section identifies generic requirements independent of the individual CDNI APIs. Some of those are expected to affect multiple or all APIs. Content licensing is typically a complex mixture of temporal restrictions (e.g., how soon after the original release date), geo- location restrictions (e.g., in which countries), device and quality restrictions (e.g., only on devices with resolutions less than WxH), and NSP restrictions. 3.1. Asymmetric Content Availability Use Case Often content is tailored to the NSP and devices supported by the NSP, e.g., NSP1 only support smart phones but not tablet devices, therefore only requires content with resolution less than 480x320. In this case, the content files available through the CDN (CDN1), operated by the NSP (NSP1), will be a subset of all available content files. A second NSP (NSP2) may support laptop and tablet devices and may therefore require higher resolution video. This CDN (CDN2), operated by NSP2, will require access to and possibly pre-positioning of different content files than CDN1. The ability to delegate requests from CDN2 to CDN1 is diminished by the availability of only a limited subset of the content files on CDN1. In this case, both CDN1 and CDN2 may be considered Authoritative CDNs, however, any resiliency measures introduced by CDN interconnection will be limited. The WMA must track and manage the rights of each Authoritative CDN to different content files and be able to set delegation policies for those CDNs. 3.2. Content Purge Use Case Temporal licensing restrictions typically consist of a "sunrise" (activation time), a "sunset" (deactivation time), and a "takedown" (expiration time). Sunrise and sunset refer to logical availability, however, takedown refers to physical availability. Service agreements must typically support takedown guarantees. The ability to both issue and confirm the expunging of content files from surrogates is required to enforce these content licenses. These licenses may have different sunrise, sunset, and takedown times for different NSPs. The WMA must track, manage, and confirm the takedown of content from each of the Authoritative CDNs that content was Ma, et al. Expires September 8, 2011 [Page 7] Internet-Draft CDNI Publisher Use Cases March 2011 provided to. In the case that an Authoritative CDN delegated delivery to a non-Authoritative CDN, confirmation of content takedown from the non-Authoritative Downstream CDNs must be confirmed as well. 3.3. Service Level Agreement Negotiation Use Case For video streaming services, the content provided for distribution is typically encoded at known bitrates. The quality of the delivered content is dependent upon the network capacity of the CDN. EU experience is critical to protecting CP brand loyalty. The content provider may wish to restrict delivery when insufficient bandwidth exists to deliver a high quality content viewing experience. The "Overload Handling" use case, discussed in [I-D.bertrand-cdni-use-cases], discusses expansion of bandwidth, but not the specific enforcement of minimum bandwidth or minimum latency requirements. Metadata needs to support the specification of these requirements. The WMA needs to be able to negotiate and set limitations for content delivery. 4. Detailed Content Delivery Use Cases This section identifies generic requirements independent of the individual CDNI APIs. Some of those are expected to affect multiple or all APIs. 4.1. Grouped File Delegation Delegating or pre-positioning content which are commonly requested in close temporal proximity is an important use case for CDN optimization and affects metadata concepts in CDN interconnection. For the delivery of streaming video, the content may be separated into multiple files, e.g., segment files for HTTP Live Streaming (HLS) [I-D.pantos-http-live-streaming]. When delegating requests for HLS content, it may not be efficient to delegate each segment file request, but rather be able to delegate sets of content files that are commonly requested as a group. Web page images and icons may also fall into this category. For streaming video, however, there is also a sequential time component for which metadata may be used to optimize paced on-demand pre-fetching of segment files. Similarly, for the case of pre-positioning grouped files, the Ma, et al. Expires September 8, 2011 [Page 8] Internet-Draft CDNI Publisher Use Cases March 2011 ability to set a priority for certain files (e.g., common video starting points or hot-spots) allow the CDN to optimize storage usage, while still pre-positioning content critical to minimizing initial delivery latency. This information, combined with geo-location information, may enable the CDN to further optimize surrogate selection. 4.2. Adaptive Bitrate Streaming Use Case Support for adaptive bitrate delivery an important use case for HTTP-based streaming video (e.g., HTTP Live Streaming (HLS) [I-D.pantos-http-live-streaming]) The CDN interconnection problem statement [I-D.jenkins-cdni-problem-statement] clearly states as a non-goal: "Content preparation, including encoding and transcoding". While the actual transformation of content is beyond the scope of CDN interconnection, the understanding about the existence of pre-transcoded files which are related to each other, is valuable for CDN pre-fetching, pre-positioning, and delivery optimization. This may be considered a further extension of the Grouped File Delegation use case. Metadata relaying the relative access patterns for specific content (e.g., switching from bitrate 6 to bitrate 7 is more likely than switching from bitrate 7 to bitrate 1) may be used to further optimize storage usage and surrogate selection. 4.3 Session Shifting Use Case Session shifting between first (TV), second (PC), and third (mobile) screen devices is a primary use case for CDN interconnection. The "Device and Network Technology Extension" use case, discussed in [I-D.bertrand-cdni-use-cases], covers a single device moving from one NSP/CDN to another (e.g., switching from WiFi to 3G on a mobile device). An extension to this scenario is switching between different devices either within the same NSP (e.g., switching from a TV on a cable network, to a PC connected to a cable modem or to a mobile device connected via WiFi to the cable modem) or across multiple NSPs (e.g., from a TV connected to a cable or a PC connected to a cable modem or a mobile device connected via WiFi to the cable modem, to a mobile device on a 3G/4G cellular connection). The requests may come from different devices and/or access networks, but all belong to the same virtual data stream. Ma, et al. Expires September 8, 2011 [Page 9] Internet-Draft CDNI Publisher Use Cases March 2011 4.4 Origin Server Failover Use Case Support for multiple origin servers from which Downstream CDNs may retrieve content is an important use case for resilient delivery. The "Overload Handling" and "Resiliency" use cases, discussed in [I-D.bertrand-cdni-use-cases], cover cases where an EU is redirected to an alternate CDN (CDN2) when the CDN which received the initial request (CDN1) is unable to service it due to capacity issues or other failure. An extension to this scenario is the condition where the origin server (OS1) becomes either temporarily or permanently unreachable to CDN1. In this case, there are two possible options: o Redirect the request to CDN2, in the hope that CDN2 still has connectivity to the origin server (OS1). o Failover to a secondary origin server (OS2) and attempt to retrieve the content from OS2 in order to service the request. There may be a arbitrary number of alternate origin servers (which may in fact be other CDNs) and failover to an alternate CDN should only occur after exhausting a possibly limited alternate origin server search. In the case of live streaming video, an origin server may go down unexpectedly, and retrieval from an alternate CDN may not be feasible if it introduces too much latency. Ma, et al. Expires September 8, 2011 [Page 10] Internet-Draft CDNI Publisher Use Cases March 2011 5. Conclusions This draft introduces some content publisher use cases that need to be considered in the CDNI efforts. We covered the cases that apply to workflow management as well as content delivery. Ma, et al. Expires September 8, 2011 [Page 11] Internet-Draft CDNI Publisher Use Cases March 2011 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations Content licensing rights need to be managed across multiple CDN domains as described in the workflow management use cases above. 7. Acknowledgements The authors would like to thank the organizers of this effort to discuss the requirements for delivering premium content over the Internet. 8. References 8.1. Normative References [I-D.bertrand-cdni-use-cases] Bertrand, G. and E. Stephan, G. Watson, T. Burbridge, P. Eardley, "Use Cases for Content Distribution Network Interconnection", draft-bertrand-cdni-use-cases-01 (work in progress), January 2011. [I-D.jenkins-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-jenkins-cdni-problem-statement-01 (work in progress), January 2011. [I-D.watson-cdni-use-cases] Watson, G., "CDN Interconnect Use Cases", draft-watson-cdni-use-cases-00 (work in progress), January 2011. [I-D.pantos-http-live-streaming] R. Pantos, "HTTP Live Streaming", draft-pantos-http-live-streaming-05(work in progress), November 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ma, et al. Expires September 8, 2011 [Page 12] Internet-Draft CDNI Publisher Use Cases March 2011 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 8.2. Informative References [Apache-Common] "Apache Common Log File Format (http://www.w3.org/Daemon/ User/Config/Logging.html#common-logfile-format)". [Apache-Format] "Apache LogFormat Directive (http://httpd.apache.org/docs/ 1.3/mod/mod_log_config.html#logformat)". [I-D.amini-cdi-distribution-reqs] Amini, L., "Distribution Requirements for Content Internetworking", draft-amini-cdi-distribution-reqs-02 (work in progress), November 2001. [I-D.cain-request-routing-req] Cain, B., "Request Routing Requirements for Content Internetworking", draft-cain-request-routing-req-03 (work in progress), November 2001. [I-D.gilletti-cdnp-aaa-reqs] "CDI AAA Requirements, draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. Ma, et al. Expires September 8, 2011 [Page 13] Internet-Draft CDNI Publisher Use Cases March 2011 Authors' Addresses Kevin Ma Azuki Systems 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 Email: kevin.ma@azukisystems.com Raj Nair Azuki Systems 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 Email: raj.nair@azukisystems.com Ma, et al. Expires September 8, 2011 [Page 14]