CDNI R. Krishnan Internet Draft Brocade Communications Intended status: Informational B. Khasnabish Expires: January 2013 ZTE Corporation July 30, 2012 Traffic management models for http adaptive-streaming-aware CDN Interconnection draft-krishnan-cdni-tm-has-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." Krishnan, et al. Expires January 30, 2013 [Page 1] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 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 This Internet-Draft will expire on Fail 30, 0000. Copyright Notice Copyright (c) 0000 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. 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. Abstract This document presents thoughts on the traffic management aspects of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to recommend traffic management techniques which can offer the best adaptive streaming performance over CDN interconnections. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. CDNi interface bandwidth challenges............................3 4. CDNi interface traffic management..............................4 4.1. WRED Configuration Example................................5 4.1.1. Router buffering and queueing recommendations........7 Krishnan, et al. Expires January 30, 2013 [Page 2] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 4.1.2. IP DSCP and Queue size mapping for IPv4 traffic recommendations.............................................7 5. References.....................................................8 5.1. Normative References......................................8 5.2. Informative References....................................8 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 pull-based mechanism, with a client actively requesting content segments, instead of the content being pushed to the client by a server. The underlying protocol used by HTTP is TCP/IP. This document presents the challenges in CDNi interface bandwidth provisioning, given the heavy asymmetric usage of the network between peak and quiet hours. The document [I-D.brandenburg-cdni-has-03] recommends various models for adaptive streaming aware CDN interconnection. This document complements the above document by recommending traffic management techniques which can offer the best adaptive streaming performance over CDN interconnections during hours of congestion. 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 [RFC2119]. This document reuses the terminology defined in: [I-D.ietf-cdni-problem-statement-06], [I-D.ietf-cdni-requirements-03], [I-D.ietf-cdni-framework-00], and [I-D.ietf-cdni-use-cases-08]. 3. CDNi interface bandwidth challenges Typically, the interface between CDNs is a long-haul backbone network where bandwidth is premium. The bandwidth needs of HAS is directly proportional to the number of active end users who are streaming video. The bandwidth requirements of HAS are quite asymmetric, with the bandwidth usage during peak family hours is substantially higher as compared to the normal hours. Caching in the CDN-I alleviates this Krishnan, et al. Expires January 30, 2013 [Page 3] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 to a certain degree, but we could have network congestion in the following scenarios 1) During peak hours, in a pull model caching, the first copy of many HAS streams would be delivered. 2) Long-tail personalized content, which is not amenable to caching, is desired by the end user. A naive solution would be to dimension the CDNi bandwidth for the peak hour usage and projected user growth which can lead to an expensive backbone network infrastructure. By using traffic management techniques described below, this issue network congestion issue can be alleviated by to a great degree and the backbone network need not be dimensioned for peak usage. 4. CDNi interface traffic management The CDNi interface links, which are typically long haul, have much lower bandwidth as compared to the links in the CDN. As discussed in the previous section, there is potential for congestion in the CDNi interface links especially during peak hours. The underlying protocol used by HAS is TCP/IP. In the standard router configuration, the default congestion avoidance behavior for TCP/IP traffic is tail drop. Tail drop causes global synchronization of TCP/IP hosts or in effect the end users of HAS. Global synchronization occurs as waves of congestion crest only to be followed by troughs during which the CDNi interface link(s) are not fully utilized. Global synchronization of TCP hosts, for example, can occur because packets are dropped all at once due to tail drop. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced. This leads to poor adaptive streaming performance when the CDNi interface links are congested especially during peak hours. Enabling Random Early Discard (RED) [RFC2309] on the CDNi interface links for HAS traffic, results in better adaptive streaming performance when the CDNi interface links are congested especially during peak hours. The following explains the WRED behavior in detail. RED aims to control the average queue size by indicating to the end hosts when they should temporarily slow down transmission of packets. WRED takes advantage of the congestion control mechanism of TCP. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. The packet source is using TCP, or in effect the HAS end user, will decrease its transmission rate until all the packets reach their destination, indicating that the congestion is cleared. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support. RED Krishnan, et al. Expires January 30, 2013 [Page 4] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 distributes losses in time and maintains normally low queue depth while absorbing spikes. Weighted Random Early Discard (WRED) is an improved version of RED which provides separate queue thresholds for different traffic classes, enabling the provision of different qualities of service for different traffic classes [RFC2474]. Using WRED, low priority HAS traffic may be dropped more frequently than high priority HAS traffic during periods of congestion. The example below demonstrates how WRED can be configured to improve HAS performance and offer differentiated services for different types of HAS traffic. 4.1. WRED Configuration Example As depicted in Figure 1, both CDN-A and CDN-B establish interconnections with CDN-C that acts as a dCDN. Thus, CDN-C will cache the content for CDN-A and CDN-B. When both CDN provider A and CDN provider B have agreements with the same CSP for content delivery, CDN-C may be required by CDN-A and CDN-B separately to retrieve and cache the same content from the CSP. WRED is enabled on the CDNi interface between CDN-A <-> CDN-C and CDN-B <-> CDN-C. The router configuration is depicted below. Krishnan, et al. Expires January 30, 2013 [Page 5] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 +-------+ | CSP | +-------+ / \ ,--,--,--./ \,--,--,--. ,-' `-. ,-' `-. ( CDN Provider A ) ( CDN Provider B ) `-. (CDN-A) ,-' `-. (CDN-B) ,-' `--'--'--' `--'--'--' \\ // WRED <---------- \\,--,--,--.// --------> WRED ,-' `-. ( CDN Provider C ) `-. (CDN-C) ,-' `--'--'--' | +------------+ | User Agent | +------------+ === CDN Interconnect Figure 1 Interconnected CDNs with WRED enabled across CDNi Krishnan, et al. Expires January 30, 2013 [Page 6] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 4.1.1. Router buffering and queueing recommendations Amount of buffers needed = Round Trip Time (RTT) x link capacity of bottleneck link; in this case, the bottleneck link is typically the CDNi link The is a separate queue per ; typically there are 8 priorities 4.1.2. IP DSCP and Queue size mapping for IPv4 traffic recommendations Map HAS traffic to a IP DSCP Assured Forwarding (AF) class, e.g. class 3 (IP precedence 3) High priority HAS traffic Marked with low drop precedence e.g. AF31 Queue threshold to trigger random packet drop - high value Drop probability - low value Medium priority HAS traffic Marked with medium drop precedence e.g. AF32 Queue threshold to trigger random packet drop - medium value Drop probability - medium value Low priority HAS traffic Marked with high drop precedence e.g. AF33 Queue threshold to trigger random packet drop - low value Drop probability - high value Krishnan, et al. Expires January 30, 2013 [Page 7] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 5. References 5.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 5.2. Informative References [I-D.ietf-cdni-framework]L. Peterson, "Framework for CDN Interconnection", April 2012. [I-D.ietf-cdni-problem-statement]B. Niven-Jenkins, "Content Distribution Network Interconnection (CDNi) Problem Statement", May 2012. [I-D.ietf-cdni-requirements]K. Leung, "Content Distribution Network Interconnection (CDNi) Requirements", December 2011. [RFC2309] B. Braden, "Recommendations on Queue Management and Congestion Avoidance", April 1998 [RFC 2474] K. Nichols, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998 Authors' Addresses Ram Krishnan Brocade Communications San Jose, 95134, USA Krishnan, et al. Expires January 30, 2013 [Page 8] Internet-Draft TM Models for HAS aware CDN Interconnection July 2012 Phone: +001-408-406-7890 Email: ramk@brocade.com Bhumip Khasnabish ZTE Corporation New Jersey, 07960, USA Phone: +001-781-752-8003 Email: bhumip.khasnabish@zteusa.com Krishnan, et al. Expires January 30, 2013 [Page 9]